5 ms·

C++ Committee don’t want to fix range-based for loop in C++23 (broken for 10yrs)

34 points by pansa2 5y ago

KronisLV 5y ago
Maybe they should just add a compiler flag and split off the behaviour, so by default the bug isn't present, but it's available for those who need it? --use-old-behaviour-range-based-for-loop
- Tajnymag 5y ago
  Are there already similar flags for other bugs in place?
  - TonyTrapp 5y ago
    In the general case, the C++ compiler always needs to know according to which C++ standard the code should be interpreted, so any code compiled as C++14 code should for example use the old behavior. More specifically, some compilers such as Microsoft's compiler support some their old bugs through specific flags (e.g. permissive mode in MSVC).
    - Tajnymag 5y ago
      Thanks. Makes sense. You are right that that's basically the reason why the standard level is such an important thing to specify while compiling.
sieabah 5y ago
Inversely, 10 years of software built around a software bug. I'm not sure why I'm seeing so many Tweets being pushed to the top of HN? Why not just link to the actual presentation and not the arguing hivemind that is Twitter? http://josuttis.de/cpp/210929_rangebasedfor_p2012r2.pdf http://josuttis.de/cpp/210929_rangebasedfor_p2012r2.pdf
- deleted 5y ago
  [deleted]
- throwaway81523 5y ago
  Thanks, that pdf was informative. I wonder if the proposed fix could introduce memory leaks in old code.
- jasode 5y ago
  >Why not just link to the actual presentation and not the arguing hivemind that is Twitter? Can't speak for the submitter but many times for technical topics, the replies add more context. In this particular case, the replies didn't have any arguing and there was also a more detailed pdf with more extensive code samples: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2012r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p201... ... was from: https://twitter.com/NicoJosuttis/status/1443453792805064706 https://twitter.com/NicoJosuttis/status/1443453792805064706
  - sieabah 5y ago
    It's only a matter of time before the "engaging" arguments are promoted to the top of a twitter feed. Maybe for extremely low traffic posts, but what I see from the top is a snarky comment from Nicolai which essentially is relaying through "yet another" segue of <insert relatable quote> along the lines of "this is stupid, they're stupid, why is this still a stupid problem to have". To his own post. The following comment about Gasper talks about how it was the approach that was incorrect, not that it shouldn't be fixed. The following response is just defending that "things must be done if asked otherwise who will do the asking" concern trolling. Below that is unrelated tweets. I'm not about to go and click through a bunch of responses and more replies searching for the discussion. Hence why I think Twitter is a terrible platform to link to. Twitter is just an engagement platform which feeds off arguments and bickering between people using snarky comments so people feel clever. Getting hearts/likes so that you know x number of people on the internet approve of your message.
nightcracker 5y ago
Rust sidesteps issues like this entirely through its Editions. Code from different editions can all each other, but editions can introduce breaking changes. For example, in Rust 2018 and earlier calling arr.into_iter() on an array type would result in an iterator over references of elements of arr (which is the expected result of .iter(), but not .into_iter()). In Rust 2021 this is fixed and arr.into_iter() will take ownership of the array and return an iterator over the values themselves. But old crates that are specified to compile using Rust 2018 will still work, and you can still call them from Rust 2021 without problems. If the C++ committee ever wants to fix its language it must introduce such backwards-incompatible changes. With the advent of modules this should be possible, you could compile each module using different editions yet still call each other.
- zigzag312 5y ago
  That is great to hear. Every language should have a way to introduce "breaking changes" without breaking old code. Without this, evolution of a language is severely limited.

34 points by pansa2 5y ago

Maybe they should just add a compiler flag and split off the behaviour, so by default the bug isn't present, but it's available for those who need it? --use-old-behaviour-range-based-for-loop

Tajnymag 5y ago
Are there already similar flags for other bugs in place?
- TonyTrapp 5y ago
  In the general case, the C++ compiler always needs to know according to which C++ standard the code should be interpreted, so any code compiled as C++14 code should for example use the old behavior. More specifically, some compilers such as Microsoft's compiler support some their old bugs through specific flags (e.g. permissive mode in MSVC).
  - Tajnymag 5y ago
    Thanks. Makes sense. You are right that that's basically the reason why the standard level is such an important thing to specify while compiling.

sieabah 5y ago

Inversely, 10 years of software built around a software bug. I'm not sure why I'm seeing so many Tweets being pushed to the top of HN? Why not just link to the actual presentation and not the arguing hivemind that is Twitter? http://josuttis.de/cpp/210929_rangebasedfor_p2012r2.pdf http://josuttis.de/cpp/210929_rangebasedfor_p2012r2.pdf

deleted 5y ago
[deleted]
throwaway81523 5y ago
Thanks, that pdf was informative. I wonder if the proposed fix could introduce memory leaks in old code.
jasode 5y ago
>Why not just link to the actual presentation and not the arguing hivemind that is Twitter? Can't speak for the submitter but many times for technical topics, the replies add more context. In this particular case, the replies didn't have any arguing and there was also a more detailed pdf with more extensive code samples: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2012r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p201... ... was from: https://twitter.com/NicoJosuttis/status/1443453792805064706 https://twitter.com/NicoJosuttis/status/1443453792805064706
- sieabah 5y ago
  It's only a matter of time before the "engaging" arguments are promoted to the top of a twitter feed. Maybe for extremely low traffic posts, but what I see from the top is a snarky comment from Nicolai which essentially is relaying through "yet another" segue of <insert relatable quote> along the lines of "this is stupid, they're stupid, why is this still a stupid problem to have". To his own post. The following comment about Gasper talks about how it was the approach that was incorrect, not that it shouldn't be fixed. The following response is just defending that "things must be done if asked otherwise who will do the asking" concern trolling. Below that is unrelated tweets. I'm not about to go and click through a bunch of responses and more replies searching for the discussion. Hence why I think Twitter is a terrible platform to link to. Twitter is just an engagement platform which feeds off arguments and bickering between people using snarky comments so people feel clever. Getting hearts/likes so that you know x number of people on the internet approve of your message.

nightcracker 5y ago

Rust sidesteps issues like this entirely through its Editions. Code from different editions can all each other, but editions can introduce breaking changes. For example, in Rust 2018 and earlier calling arr.into_iter() on an array type would result in an iterator over references of elements of arr (which is the expected result of .iter(), but not .into_iter()). In Rust 2021 this is fixed and arr.into_iter() will take ownership of the array and return an iterator over the values themselves. But old crates that are specified to compile using Rust 2018 will still work, and you can still call them from Rust 2021 without problems. If the C++ committee ever wants to fix its language it must introduce such backwards-incompatible changes. With the advent of modules this should be possible, you could compile each module using different editions yet still call each other.

zigzag312 5y ago
That is great to hear. Every language should have a way to introduce "breaking changes" without breaking old code. Without this, evolution of a language is severely limited.