|
[Rivet] Minor problems in Rivet 1.5.0Andy Buckley andy.buckley at ed.ac.ukTue May 10 13:13:58 BST 2011
On 18/03/11 20:29, Leif Lönnblad wrote: > On 2011-03-18 16:46, Andy Buckley wrote: >> Wow, please do! > > Done. [revisiting this old thread, since I just attempted to put in the nice singleton implementation for ProjectionHandler again, and it still crashes... looks like that was/is a somewhat separate issue :( ] >> I thought that reset *was* the Boost shared_ptr way of >> assigning a shared ptr value, and was in some way more suitable than the >> operator=, cf. operator[] on std::map -- I didn't realise that they had >> different semantics about the implied ownership. Seems I have some >> re-reading of the Boost pointer definitions to do. Thanks, Leif :) >> >> I believe that there is still a problem in that the projection >> shared_ptrs are then put into a std::set, but that operator<(shared_ptr, >> shared_ptr) is not quite what you think it should be. But perhaps by >> changing the ownership as above, this issue is also resolved: the >> comparison operator distinction also related to the ownership. > > Well, again according to the boost reference manual, the operator< for > shared pointers is designed to be used in sets and maps. > >> I can also now test putting back the fixed versions of some singletons >> as well... when I tried to do this before, it turned out that cleaning >> them up properly resulted in a segfault at the end of every Rivet job! > > Isn't the whole point that they should clean themselves up in the end? Yes, but the right number of times! But very possibly it's doing the right thing, but my ProjectionHandler code is using it the wrong way. I'll commit my changes now, but with the better singleton commented out for now: we can then make the 1.5.1 release and I think we should then pull the singleton into the trunk, where it *will* break things. Hopefully we can work out together what's going wrong, since my understanding of how to use shared_ptr is clearly a bit shaky (and I've not been able to find a good tutorial to make it really clear.) Hopefully it's something simple... how did you track down the previous "abused reset()" issue, Leif? Andy -- Dr Andy Buckley SUPA Advanced Research Fellow Particle Physics Experiment Group, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
More information about the Rivet mailing list |