Mathias Gaunard wrote:
Phil Endecott wrote:
- It would be good if the docs were explicit about this being a thin wrapper around your existing std::sort, and identifying those algorithms that are not so thin.
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.
unique(vec);
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. There is a lot of stuff in C++ that is more complicated to use than it could be. We have all got used to how things are and know the reasons why, but it presents an obstacle to new users. This library reduces some of this complexity, which is really great. I suggest that we consider how much further we can go in this direction. Maybe algorithms that really take containers, rather than ranges, are beyond the scope of this library. Or maybe not.
However, uniqued(vec) returns a new lazy range without duplicates (if the range is sorted), and unique_copy(vec) returns a new range without duplicates.
Neither allows me to unique a container in-place though. Cheers, Phil.