- Forum
- General C++ Programming
- Why no overload std::max_element(vector)
Why no overload std::max_element(vector)
Hi, two questions:
1) Is there a "good" reason why there isn't alread an overload for std::max_element that takes a vector and assumes first = std::begin(v) and last = std::end(v), in <algorithm> itself ?
2) Is there a suggestion box for developers of the C++ language ? To add this suggestion to it?
Cheers,
1) Is there a "good" reason why there isn't alread an overload for std::max_element that takes a vector and assumes first = std::begin(v) and last = std::end(v), in <algorithm> itself ?
2) Is there a suggestion box for developers of the C++ language ? To add this suggestion to it?
Cheers,
(1) The standard library works with iterators in many places in that way.
https://softwareengineering.stackexchange.com/questions/231336/why-do-all-algorithm-functions-take-only-ranges-not-containers
One issue is that std::end() and std::begin() as free functions didn't exist until C++11. But still, come C++11, they could have added a template overload that took in the container itself, so this isn't really an excuse.
But the thing is, the functions in <algorithm> are intended to make functionality like that reusable as much as possible, with little bloat. All the functionality that you need is already provided in the current max_element function template, so the standard library committee didn't feel the need to add more onto that.
There's more reasons listed in the link above, so as also being able to do reverse iteration on a container.
(2) Please see: https://isocpp.org/std/submit-a-proposal
(But as Peter said, apparently boost's version of this is being integrated with the standard after all!)
https://softwareengineering.stackexchange.com/questions/231336/why-do-all-algorithm-functions-take-only-ranges-not-containers
One issue is that std::end() and std::begin() as free functions didn't exist until C++11. But still, come C++11, they could have added a template overload that took in the container itself, so this isn't really an excuse.
But the thing is, the functions in <algorithm> are intended to make functionality like that reusable as much as possible, with little bloat. All the functionality that you need is already provided in the current max_element function template, so the standard library committee didn't feel the need to add more onto that.
There's more reasons listed in the link above, so as also being able to do reverse iteration on a container.
(2) Please see: https://isocpp.org/std/submit-a-proposal
(But as Peter said, apparently boost's version of this is being integrated with the standard after all!)
Last edited on
| In C++20 you will be able to call std::ranges::max_element(v). |
Right, to be described here
https://en.cppreference.com/w/cpp/algorithm/ranges#Minimum.2Fmaximum_operations
until then, there's always boost: https://www.boost.org/doc/libs/1_68_0/libs/range/doc/html/range/reference/algorithms/non_mutating/max_element.html
@Cubbi, can you explain what the parenthesized term "niebloid" means in that first link?
I can only assume it has something to do with Eric Niebler, but that's just a guess. (And I wonder what he thinks about that term!)
I can only assume it has something to do with Eric Niebler, but that's just a guess. (And I wonder what he thinks about that term!)
Last edited on
| mbozzi wrote: |
|---|
| can you explain what the parenthesized term "niebloid" means in that first link? |
in practice, function objects that pretend to behave like the old <algorithm> function templates, except for no ADL.
| mbozzi wrote: |
|---|
| I wonder what he thinks about that term |
Last edited on
Topic archived. No new replies allowed.