Subject: Re: [boost] RangeEx review
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-03-01 11:24:36
Phil Endecott wrote:
> Mathias Gaunard wrote:
>> Actually, I believe sort(c) calls c.sort() if it exists.
>> So it's not just std::sort.
>
> I don't see any evidence of that in boost/range/algorithm/sort.hpp.
> Where should I be looking? This would of course be a useful feature,
> and documenting whether it is or is not done would be useful.
It is done by the range_ex version in the sandbox.
Maybe it has been dropped then, a rationale for that would be nice.
>>> My point is that std::unique only has its "move duplicates to the
>>> end" behaviour because the conventional interface with a pair of
>>> iterators doesn't let you change the size of the container. Now that
>>> we have a unique() that takes a container we don't need that
>>> restriction.
>>
>> Not a container, a range.
>
> The fact that the container that I pass is converted to a range can be
> considered as an implementation detail for many applications of this
> library.
So you would want unique to have different semantics whether the passed
range is a container or not?
It would probably be best to have "unique" have the same semantics as
std::unique and "unique_inplace" have the semantics you want.
Also, for a container such as vector, should unique_inplace actually
move the elements to remove to the end before erasing them, since that
should be more efficient, or should it erase duplicates as they are found?