Boost logo

Boost :

From: Jordan DeLong (fracture_at_[hidden])
Date: 2006-02-25 21:54:20


The other day I was working on an application where I ended up putting
some COM pointers wrapped in boost::shared_ptr<> into a map as keys.
Something like std::map<boost::shared_ptr<IUnknown>,some_data>

For any who don't know: in COM, you have to turn pointers into
'IUnknown' pointers before you can reliably compare them for identity
using a QueryInterface() function. This returns a brand new
reference, which I would then wrap into a new shared_ptr<> (with a
custom deleter that calls Release), in a similar manner to an example
shared_from_com() function found in the boost::shared_ptr<>
documentation.

So, the problem I ran into is that the "same" pointers still would end
up as unique entries in the map, because the operator< defined for
shared_ptr's goes both based on the pointer values and whether or not
the shared_ptr's have the same shared_count pointer. This is very
easy to fix, of course: I can just define a custom sort function for
the map that returns `a.get() < b.get()'.

But the suprising thing is that this has the effect of making the
expressions: `a == b' and `!(a < b) && !(b < a)' for shared_ptr's `a'
and `b' possibly return different values, because operator== is simply
defined as `a.get() == b.get()'.

Anyway, I would imagine there is probably a good reason for this
design, because it looks deliberate. Also, I would assume it is
probably part of tr1::shared_ptr<> now. But I was curious what the
reasoning was.

-- 
Jordan DeLong
fracture_at_[hidden]



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk