|
[Rivet] Dangerous casting to FinalStateDavid Bjergaard david.bjergaard at gmail.comFri Mar 13 14:45:28 GMT 2015
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
More information about the Rivet mailing list |