Hacker News Reader

Comment by layoutIfNeeded | Hacker News Reader

It’s literally a 3-line utility if you want that:

  template<typename T> void sort(T& t) {
    std::sort(std::begin(t), std::end(t));
  }

View on HN

Sure. But this is the kind of thing that you would use if it were in the standard headers, but maybe not create (or modify, if it already exists) a work_around_cxx_deficiencies.h in the project and make sure it's included everywhere. Or maybe it's already included in some misc_utils.h in the project but is not easily discoverable, since such "misc utils" headers are always a grab-bag of random unrelated stuff. Whatever the reason, in the C++ projects I worked on we always ended up using the iterator version. We certainly would have used the non-iterator version if it had been available from the standard headers.

In the ideal world ranges would have been in the original standard, but there were two issues.

First, at the time the language did not have enough forwarding capabilities, so you would have needed a lot of overloads to handle const and non const containers.

Second getting anything approved in committee is a huge effort so often proposals are stripped to the bare minimum; in particular the STL was already huge and Stepanov tried to include only what he thought were the fundamental components.

The new ranges have been in development for almost 10 years (arguably they suffered a bit of mission creep), so it is not just a matter of adding range overloads for functions.

I wasn't talking about ranges, I was talking about the grandparent's three-line wrapper function.

well, first of all that wrapper uses std::being/std::end which wasn't available in c++98, second std::sort is "easy" as it is mutating and it doesn't return anything. For other algorithms you want to return ranges (For composability) and things get more complicated.

Regarding the first point: True, but the wrapper could also have been written in terms of foo.begin()/foo.end(), no? Second point: Yes, I would want the easy case solved. Obviously, if an algorithm cannot be wrapped like this, then I'm not asking for the impossible.

No, at least not without a separate overload for C-style arrays. If you don’t care about C arrays then yes, .begin/.end could work.

All generic container manipulating functions use iterations - each of which you’d have to write a utility function for, just to use a couple of times.

What would otherwise be a trivial one liner with something like transform suddenly turns into a 3 line call

Reply on news.ycombinator.com