|
[Rivet] Dangerous casting to FinalStateFrank Siegert frank.siegert at cern.chMon May 4 17:04:45 BST 2015
Hi Andy, > Does that problem disappear if you define remainder as a reference, > either as VetoedFinalState& or FinalState&? Yes, even for FinalState& the problem disappears. That's case 2a in my original examples. > It would also be useful if you could use the -l TRACE flag (if I > remember the syntax correctly) when running, and send the resulting log > so we can see if that parent address corresponds to something. Offhand > it looks like a bit of an odd address value: is this the sort of pointer > value that corresponds to a non-heap-allocated local? I have no idea on the pointer value here, but I have put the full log into http://cern.ch/fsiegert/tmp/trace.log > When assigning a Projection like this, a copy will be made. Does > VetoedFinalState have a copy assignment operator, copy constructor, etc. > defined as per the Rule of Three > (http://en.wikipedia.org/wiki/Rule_of_three_%28C%2B%2B_programming%29) > to make this safe? I genuinely can't remember if we do that, since > copying of projections isn't really the idea. If we don't perhaps we > could make it a rule in Projection implementation to always hide (i.e. > make private) the copy constructor and copy assignment operators to > simply ban copy by value and hence force use of references. I forget if > this can be done on the Projection base class or if each new derived > class would need to explicitly re-hide them. Anyway, food for thought > albeit not quite at black belt level ;-) We don't seem to explicitly define any of the three (copy assignment operator, copy constructor, destructor). I guess the copying that you mean stems from the clone() function, which probably is using the constructor from a FinalState instead of a copy constructor? If our projection registration/cloning can't cope with normal C++ copying then we should indeed either fix it or hide the copy constructors/operators. I have to admit that I didn't even realise that we are internally cloning projections upon registration, and whatever magic is connected to that. It's probably nothing super-urgent to fix, since at least it won't give wrong results. But I'd expect the black-belts to understand this much better than I (challenge!). Cheers, Frank
More information about the Rivet mailing list |