[Rivet] Minor problems in Rivet 1.5.0

Leif Lönnblad leif.lonnblad at thep.lu.se
Fri 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