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?