News for hackers. Stuff that matters.
Re:C++ the Good Parts (2014) by gpderetta on Thursday October 01, 2020 @07:33AM (#24649708)
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.

Re:C++ the Good Parts (2014) by tom_mellior on Thursday October 01, 2020 @08:10AM (#24649973)
I wasn't talking about ranges, I was talking about the grandparent's three-line wrapper function.
Re:C++ the Good Parts (2014) by gpderetta on Thursday October 01, 2020 @08:22AM (#24650052)
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.
Re:C++ the Good Parts (2014) by tom_mellior on Thursday October 01, 2020 @10:23AM (#24651133)
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.
Re:C++ the Good Parts (2014) by layoutIfNeeded on Thursday October 01, 2020 @10:56AM (#24651551)
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.