6 ms·

The best part by far: for(const auto& item : dummy_list) { ... } It was fucking ugly and verbose use iterators for something so basic and simple.

tom_mellior 6y ago
What I always found weird and verbose were all the algorithms taking begin-end iterator pairs, like: std::sort(my_container.begin(), my_container.end()); I mean, yes, in 0.1% of all cases I would want to sort something that is not an entire container, and for that it's great that this exists. But for the 99.9%, why isn't there an overload that would allow me to do: std::sort(my_container);
- makapuf 6y ago
  IIUC you have this using `ranges` (which itself needs concepts as implemented). With it you can even do : for (int i : ints | std::views::filter(even) | std::views::transform(square)) { std::cout << i << ' '; } notice the `for (int i:ints)` and the pipes filters. EDIT: more specifically, you can use sort on a range now (source : https://cppreference.com https://cppreference.com): ranges::sort(s);
  - dgellow 6y ago
    Wow, that pipe syntax is quite nice! Documentation here: https://en.cppreference.com/w/cpp/ranges https://en.cppreference.com/w/cpp/ranges. They are called "range adaptors" (weird naming IMHO).
    - saagarjha 6y ago
      They take a range and adapt it into a view, hence the name.
  - innot 6y ago
    The same functionality has been in boost [0] for quite a while. So, if you can't see the ugly iterators anymore, but have an outdated compiler, this is an option. [0] https://www.boost.org/doc/libs/1_72_0/libs/range/doc/html/index.html https://www.boost.org/doc/libs/1_72_0/libs/range/doc/html/in...
  - account42 6y ago
    I wish they had just added the overloads to the std:: namespace though - breaking a few obscure cases would have been worth that.
    - gumby 6y ago
      > breaking a few obscure cases would have been worth that The committee is very reluctant to break old code. That's one of the reasons the language as documented is so large. That being said it's not clear to me what would have broken by putting sort(x) into std:: as you recommend.
- layoutIfNeeded 6y ago
  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)); }
  - tom_mellior 6y ago
    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.
    - gpderetta 6y ago
      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.
      - tom_mellior 6y ago
        I wasn't talking about ranges, I was talking about the grandparent's three-line wrapper function.
        gpderetta 6y ago
        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.
hoseja 6y ago
This has a giant glaring flaw that is only just being remedied: traversing more containers at the same time or, tangentially, enumeration (i.e. availability of the index variable in the loop body).
- gpderetta 6y ago
  the expectation was always that you would use a library level adaptor (something like enumerate() or zip());

tom_mellior 6y ago

What I always found weird and verbose were all the algorithms taking begin-end iterator pairs, like: std::sort(my_container.begin(), my_container.end()); I mean, yes, in 0.1% of all cases I would want to sort something that is not an entire container, and for that it's great that this exists. But for the 99.9%, why isn't there an overload that would allow me to do: std::sort(my_container);

makapuf 6y ago
IIUC you have this using `ranges` (which itself needs concepts as implemented). With it you can even do : for (int i : ints | std::views::filter(even) | std::views::transform(square)) { std::cout << i << ' '; } notice the `for (int i:ints)` and the pipes filters. EDIT: more specifically, you can use sort on a range now (source : https://cppreference.com https://cppreference.com): ranges::sort(s);
- dgellow 6y ago
  Wow, that pipe syntax is quite nice! Documentation here: https://en.cppreference.com/w/cpp/ranges https://en.cppreference.com/w/cpp/ranges. They are called "range adaptors" (weird naming IMHO).
  - saagarjha 6y ago
    They take a range and adapt it into a view, hence the name.
- innot 6y ago
  The same functionality has been in boost [0] for quite a while. So, if you can't see the ugly iterators anymore, but have an outdated compiler, this is an option. [0] https://www.boost.org/doc/libs/1_72_0/libs/range/doc/html/index.html https://www.boost.org/doc/libs/1_72_0/libs/range/doc/html/in...
- account42 6y ago
  I wish they had just added the overloads to the std:: namespace though - breaking a few obscure cases would have been worth that.
  - gumby 6y ago
    > breaking a few obscure cases would have been worth that The committee is very reluctant to break old code. That's one of the reasons the language as documented is so large. That being said it's not clear to me what would have broken by putting sort(x) into std:: as you recommend.
layoutIfNeeded 6y ago
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)); }
- tom_mellior 6y ago
  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.
  - gpderetta 6y ago
    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.
    - tom_mellior 6y ago
      I wasn't talking about ranges, I was talking about the grandparent's three-line wrapper function.
      - gpderetta 6y ago
        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.

hoseja 6y ago

This has a giant glaring flaw that is only just being remedied: traversing more containers at the same time or, tangentially, enumeration (i.e. availability of the index variable in the loop body).

gpderetta 6y ago
the expectation was always that you would use a library level adaptor (something like enumerate() or zip());