[Rivet] Dangerous casting to FinalState

[Frank Siegert]

Thanks David for the feedback.

I'm hoping to get more feedback from the other Riveters as well. Just
to recap, there are two issues with my patch:

(i) 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?

(ii) My example 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'm attaching again the three files from back then in case somebody
doesn't find them anymore.

Cheers,
Frank



On 14 March 2015 at 20:45, David Bjergaard <david.bjergaard at gmail.com> wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hidden-copy.patch
Type: text/x-patch
Size: 4621 bytes
Desc: not available
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20150324/66602924/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MY_RFSTEST2c.cc
Type: text/x-c++src
Size: 1430 bytes
Desc: not available
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20150324/66602924/attachment.cc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zee.hepmc
Type: application/octet-stream
Size: 3305 bytes
Desc: not available
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20150324/66602924/attachment.obj>