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
Member Function Documentation
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. Does NOT look in declQueue
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. Does look in the declQueue, but NOT recursively (yet?).
Referenced by Rivet::ProjectionApplier::getProjection().
The documentation for this class was generated from the following file:
Generated on Thu Feb 29 2024 15:46:48 for Rivet by 1.9.8