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@allusion.net