[Rivet] Dangerous casting to FinalState

[Frank Siegert]

Thanks, I have pushed this to the main repo now, let me know if
anybody sees problems.

Cheers,
Frank

PS: Sorry about the unnecessary blankline removal in the diff, only
noticed it after pushing.


On 14 July 2015 at 16:13, Andy Buckley <andy.buckley at cern.ch> wrote:
> For what it's worth, I'm happy to put the patch into this release. It'll
> block compilation of code with FinalState projection slicing, albeit
> with an unclear error message, and I think we do want that.
>
> For the following major release, it'd be good to solve this more
> completely. FinalStates are the only significant subset of projections
> which can have this problem, because FinalState itself is not virtual.
> If we were to make it virtual (maybe renaming to FinalStateBase), and
> push the charged+neutral final particle finding job into another derived
> class, then there would be no problem. We anyway need to rationalise the
> relationship between ParticleFinders and FinalStates (and I think we
> should also remove the LossyFinalState and all the surrounding,
> virtually unused, mechanisms.)
>
> 'Nuff said; full speed ahead ;-)
>
> Andy
>
>
> On 14/07/15 14:17, Chris Pollard wrote:
>> Hi Frank,
>>
>> I don't see any objections, so could you include your patch and push to
>> the main repo? I will then run the validation tonight.
>>
>> Chris
>>
>> On Mon, Jul 13, 2015 at 7:35 PM, Frank Siegert <frank.siegert at cern.ch
>> <mailto:frank.siegert at cern.ch>> wrote:
>>
>>     Hi Chris,
>>
>>     >> So we might as well go ahead with my patch, since it will save users
>>     >> from this silly slicing mistake. And we will have to fix the
>>     >> projection registration mechanism anyway if we want to allow copying
>>     >> of projections by value. Though I didn't quite understand David's last
>>     >> comment: do you find the patch ok, or not (assuming we only care about
>>     >> FinalState-derived projections at the moment)? Any other objections?
>>     >
>>     > I don't object to the solution per se, but my preference is to fix the
>>     > copy-by-value issue correctly throughout the Projection inheritance
>>     > hierarchy instead of patching just FinalState. If this is the solution we
>>     > choose, great, but let's fix the whole tree. Do you agree?
>>
>>     Sounds good to me. Do you plan to have this already for this release?
>>     If not, I still see no reason to not use my patch as an intermediate
>>     stop-gap measure, which will be amended by a solution for all
>>     Projections at some point.
>>
>>     Cheers,
>>     Frank
>>
>>
>>
>>
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> https://www.hepforge.org/lists/listinfo/rivet
>>
>
>
> --
> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow