[Rivet] Fwd: Re: chaining projections together in analysis code

[David Grellscheid]

Sorry, forgot the list copy...

-------- Original Message --------
Subject: Re: [Rivet] chaining projections together in analysis code
Date: Fri, 17 Jan 2014 09:27:31 +0000
From: David Grellscheid <david.grellscheid at durham.ac.uk>
To: William Hamish Bell <w.bell at cern.ch>

Hi Will,

> Since the constructor expects a reference to a FinalState instance,
> there is a dynamic_cast on a pointer to the instance.

That's not needed. Since IdentifiedFinalState is also a FinalState, you
don't need to do any casting explicitly. The constructor of
FromElectroweakDecay will accept it anyway:
http://www.cplusplus.com/doc/tutorial/polymorphism/

However, I have no idea what it will then do with it, since
FromElectroweakDecay is not in the standard Rivet distro. All standard
projections are written to allow projection chaining in the way you do
it here.

See you,

  David



On 16/01/14 13:22, William Hamish Bell wrote:
> Hi,
> 
> I would like to chain together two projections that both inherit from
> FinalState.  Ideally, one would like to produce a projection from the
> combination of the requirements in the analysis code, e.g.:
> 
> // Projection to find the electrons std::vector<std::pair<double,
> double> > eta_elec; eta_elec.push_back(make_pair(-2.5,2.5)); 
> IdentifiedFinalState el_id(eta_elec, 25.0*GeV); 
> el_id.acceptIdPair(PID::ELECTRON); FinalState *fs =
> dynamic_cast<FinalState*>(&el_id); assert(fs); FromElectroweakDecay
> elecs(*fs); addProjection(elecs, "elecs");
> 
> Since the constructor expects a reference to a FinalState instance,
> there is a dynamic_cast on a pointer to the instance.  The code
> compiles and runs, but it is safe in terms of the Rivet design?  (I
> am using Rivet 2.0.0)
> 
> Thanks and best regards,
> 
> Will _______________________________________________ Rivet mailing
> list Rivet at projects.hepforge.org 
> http://www.hepforge.org/lists/listinfo/rivet
>