Re: [boost] smart_ptr changes

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-19 12:12:26

From: "Darin Adler" <darin_at_[hidden]>
> But this doesn't seem to be an argument for or against a boost::swap
> function. So it doesn't seem relevant to my point (e).
>
> A boost::swap function is helpful in at least two ways:
>
>     1) more efficiency with some standard library implementations -- this
is
> a Boost quality of implementation issue for me at least
>     2) if shared_ptr goes into std::, helps remind implementers that a
> std::swap overload would be appropriate

This is directly related to the infamous LWG issues #225 and #226. Without a
resolution, implementations shouldn't call the boost:: overload, so we'd
still end up relying on something that is not 'by the book.'

> > Only operator< is provided since standard algorithms usually don't need
the
> > other versions. Providing the other operators implies that shared_ptr
> > comparisons are a feature.
>
> I think that providing operator< does this too, without a comment to
explain
> the rationale. While the partial specialization of std::less is illegal
and
> this is legal, I think that a class that supports operator< but not other
> comparison operators is still a curious anomaly, more evidence of "longing
> for a key comparison abstraction".

Actually it's not longing for a key comparison abstraction, but for an
ordering abstraction (is a before b?)

We're stuck with the original STL choice to use operator< to represent
ordering, though. Another area where the age of the library shows itself.
Personally, I can live with this representation; some types are comparable,
others are merely ordered.

> But this request for rationale is a minor point.

I'm definitely _not_ opposed to providing a rationale, in the code or in the
documentation. This would be a very good thing to do.

--
Peter Dimov
Multi Media Ltd.