[Rivet] Dangerous casting to FinalState

[David Bjergaard]

Ah,

Sorry I forgot to "make install" after applying the patch. I can at
least confirm the crash:
> rivet --pwd -a MY_RFSTEST2c zee.hepmc 
> Rivet trunk running on machine calypso (x86_64)
> Rivet.Analysis.Handler: WARN  Analysis 'MY_RFSTEST2c' is unvalidated: be careful, it may be broken!
> Error in MY_RFSTEST2c::init method: No projections registered for parent 0x7fff6d42d9a0

David Bjergaard <david.bjergaard at gmail.com> writes:

> Hi Frank,
>
> For some reason your test works (with the patch): 
>> rivet --pwd -a MY_RFSTEST2c zee.hepmc 
>> Rivet trunk running on machine calypso (x86_64)
>> Rivet.Analysis.Handler: WARN  Analysis 'MY_RFSTEST2c' is unvalidated: be careful, it may be broken!
>> Reading events from 'zee.hepmc'
>> zfinder: -11 10022
>> zfinder: 11 10021
>> rfs.size = 8
>>   rfs[0] = 2103 10006
>>   rfs[1] = 2 10007
>>   rfs[2] = 2103 10009
>>   rfs[3] = 2 10010
>>   rfs[4] = 21 10015
>>   rfs[5] = 21 10016
>>   rfs[6] = -4 10017
>>   rfs[7] = 4 10018
>> Finished event loop
>> Rivet.Analysis.Handler: INFO  Finalising analyses
>> Rivet.Analysis.Handler: INFO  Processed 1 event
>
>> The MCnet usage guidelines apply to Rivet: see http://www.montecarlonet.org/GUIDELINES
>> Please acknowledge plots made with Rivet analyses, and cite arXiv:1003.0694 (http://arxiv.org/abs/1003.0694)
>> Cross-section = 1.515878e+03 pb
> I wonder if its a compiler difference?
>> g++ --version
>> g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2
>> uname -a
>> Linux calypso 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> Cheers,
>
>     Dave
>
> Frank Siegert <frank.siegert at cern.ch> writes:
>
>> Hi David,
>>
>> Thanks for your feedback.
>>
>>> Just thinking out loud:
>>> addProjection is templated on a reference, is it possible to make a
>>> specialized template for the non-reference version?
>>>
>>> Something like:
>>>     template <typename PROJ>
>>>     const PROJ& addProjection(const PROJ proj, const std::string& name) {
>>>       std::cerr<<"Please be careful about using references!"<<std::endl;
>>>       return proj;
>>>     }
>>
>> But we would not want to prevent *registering* projections by copy,
>> since that's in general absolutely fine, right? It's rather the
>> copying of a derived projection, e.g. VetoedFinalState, into a
>> FinalState that seems dangerous to me.
>>
>> I have just tested that it's possible to hide the copy constructor,
>> and am attaching a patch for Rivet which shows how this would work in
>> real life. It's a bit ugly to have to hide this for each derived
>> FinalState explicitly, I don't know whether there is any better way to
>> disallow such "lossy" copying altogether for a base class?
>>
>> With this patch Rivet compiles fine, and a few of the typical ZFinder
>> analyses seem to work as expected. Furthermore, an accidental VFS ->
>> FS copying like in my Example 1 now fails as expected and 2a and 2b
>> work as expected. But 2c is a bit strange... it compiles fine, but at
>> runtime fails with:
>> Error in MY_RFSTEST2c::init method: No projections registered for
>> parent 0x7fff33dc1630
>>
>> I don't at all understand where that's coming from, but there is a lot
>> of casting in the projection registration going on. Any ideas? I'm
>> attaching a simple analysis that demonstrates this behaviour, together
>> with one Zee event for testing.
>>
>> Cheers,
>> Frank