Boost logo

Boost :

From: Darin Adler (darin_at_[hidden])
Date: 2001-10-19 11:05:00


on 10/18/01 10:51 AM, Peter Dimov at pdimov_at_[hidden] wrote:

> From: "Darin Adler" <darin_at_[hidden]>
>> Things in there that I like, but I'd like to see taken further:
>>
>> e) removal of std::swap overload is good, but I'd like to see a
>> boost::swap overload added, since that has good effects for standard
>> library algorithms with MSL at least, even if the improvement is not
>> guaranteed by the standard
>
> I've removed the std::swap overload only because it's currently illegal, and
> I believe that boost should not endorse such practice since many users base
> their own designs on the boost implementations.

Agreed.

> When shared_ptr goes into std:: the implementors would be free to overload
> swap() as appropriate.

Yes.

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

>> f) removal of std::less partial specialization and addition of <
>> operator is good, but I'd like to either see the other comparison
>> operators or a rationale for why they are not provided
>
> 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".

But this request for rationale is a minor point.

    -- Darin


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