Re: [boost] RangeEx review

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?