[Rivet] Minor problems in Rivet 1.5.0

Andy Buckley andy.buckley at ed.ac.uk
Tue 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