Rivet
1.8.3
|
The projection handler is a central repository for projections to be used in a Rivet analysis run. More...
#include <ProjectionHandler.hh>
Public Types | |
enum | ProjDepth { SHALLOW, DEEP } |
Enum to specify depth of projection search. | |
typedef set< ProjHandle > | ProjHandles |
Typedef for a vector of Projection pointers. | |
typedef map< const string, ProjHandle > | NamedProjs |
Typedef for the structure used to contain named projections for a particular containing Analysis or Projection. | |
Public Member Functions | |
void | clear () |
Projection registration | |
| |
const Projection & | registerProjection (const ProjectionApplier &parent, const Projection &proj, const string &name) |
Attach and retrieve a projection as a reference. | |
const Projection * | registerProjection (const ProjectionApplier &parent, const Projection *proj, const string &name) |
Attach and retrieve a projection as a pointer. | |
Projection retrieval. */ | |
const Projection & | getProjection (const ProjectionApplier &parent, const string &name) const |
set< const Projection * > | getChildProjections (const ProjectionApplier &parent, ProjDepth depth=SHALLOW) const |
Static Public Member Functions | |
static ProjectionHandler & | getInstance () |
Singleton creation function. | |
Friends | |
class | ProjectionApplier |
ProjectionApplier's destructor needs to trigger cleaning up the proj handler repo. | |
The projection handler is a central repository for projections to be used in a Rivet analysis run.
Without centralised projections, it can be hard to know which of an equivalent set of projections will be run on a particular event. In turn, this may mean that certain projections in the chain can go out of scope unexpectedly. There were originally also the issues that projections may need to be held as member pointers to an abstract base class, since post-construction setup is needed; that projections contained pointers to their own dependency chain, which could go out of scope; and that projection members could be modified after being applied to an event which, due to the caching model, would have unpredictable consequences.
By centralising all the projections, these issues are eliminated, as well as allowing analysis classes to contain fewer data members (since projections are now better accessed by name than by storing a data member reference or pointer).
The core of the ProjectionHandler design is that it is a singleton class, essentially a wrapper around a map of Projection*
, indexed by a hash of the registering object and its local name for the registered projection.
void Rivet::ProjectionHandler::clear | ( | ) |
Projection clearing method: deletes all known projections and empties the reference collections.
set< const Projection * > Rivet::ProjectionHandler::getChildProjections | ( | const ProjectionApplier & | parent, |
ProjDepth | depth = SHALLOW |
||
) | const |
Get child projections for the given parent. By default this will just return the projections directly contained by the parent, but the depth argument can be changed to do a deep retrieval, which will recurse through the whole projection chain. In this case, there is no protection against getting stuck in a circular projection dependency loop.
const Projection & Rivet::ProjectionHandler::getProjection | ( | const ProjectionApplier & | parent, |
const string & | name | ||
) | const |
Retrieve a named projection for the given parent. Returning as a reference is partly to discourage ProjectionApplier classes from storing pointer members to the registered projections, since that can lead to problems and there is no need to do so.
Referenced by Rivet::ProjectionApplier::getProjection().