|
[Rivet] Minor problems in Rivet 1.5.0Leif Lönnblad leif.lonnblad at thep.lu.seFri Mar 18 20:29:38 GMT 2011
On 2011-03-18 16:46, Andy Buckley wrote: > Wow, please do! Done. > 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? > > We'll have to test this a bit, but combined with a few more analyses it > would be a nice thing to have in a 1.5.1 patch release, while we get on > in parallel with histogramming improvements. Sounds good. I wouldn't mind hearing what you have in mind for the histograms. Although I'm to blame for LWH, I may have some input to the discussions. /Leif
More information about the Rivet mailing list |