3 ms·

How hard is it to read a "for" loop? Even when programming in python, half the time I find myself switching to a simple loop over an index because I realize I n

How hard is it to read a "for" loop? Even when programming in python, half the time I find myself switching to a simple loop over an index because I realize I need the index. Often it's for debugging, because that index has a real meaning I can interpret when I see it. Along those lines, I think the real disconnect in the argument here is in terms of what kind of problem people are programming for. For many applications, advanced C++ is solving problems they don't have. The above poster mentioned audio. The data there is in single (or perhaps few) big buffers with a very simple and regular structure determined by international standards. They only need a few simple pointers. Or maybe just std::vector. Similarly just a few types also with real-world meanings. Debugging may require them to check the processing in ways that abstraction, type-checking, etc. will only get in the way of. And new features may not work within whatever abstractions had been put into place for previous features anyway, because the features relate to the underlying data.

dragonwriter 5y ago
> Even when programming in python, half the time I find myself switching to a simple loop over an index because I realize I need the index. If you need to iterate over an iterable xs and discover you need the index as well, in Python you shouldn't switch to a loop over the index, you should switch from: for x in xs: ... to: for idx, x in enumerate(xs): ...
maccard 5y ago
> How hard is it to read a "for" loop? for (std::unordered_map<std::string, int>::const_iterator it = some_map.cbegin();it != some_map.end(); ++it) is pretty damn unreadable (and for bonus points it doesn't compile) compared to for (const auto& keypair : some_map) Which doesn't have the possibility of the issue in the previous snippet (cbegin != end rather than cbegin != cend) > For many applications, advanced C++ is solving problems they don't have. No-one here is talking about advanced c++, we're talking modern c++. > The above poster mentioned audio. ... They only need a few simple pointers... And we all know that audio is immune from massive security vulnerabilities, right? [0] "New" features like nullptr (instead of NULL), unique_ptr, move semantics as examples can just flat out avoid classes of bugs that come up in low level programming, and features like constexpr and static assert can make runtime checks compile time checks instead. All these features can be escape hatched if you really really need to just cast to a void pointer to fill a buffer at the end, but the surface area for nasty bugs is significantly reduced if you do so. [0] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-41331 https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
- simplestats 5y ago
  Your examples might fit the discussion better if you made unreadable C++03 code that worked. But nonetheless, I don't agree. I can directly read what your first attempt at a loop is trying to do. Your second one hides almost everything from me. If the second one fails to compile and gives me a paragraph-long encrypted complaint, I need to somehow half-comment the thing out and create a bunch of test code so I can go in the debugger and figure out what you are actually doing. Are you saying the creation of security vulnerabilities has decreased in the last ten years. edit: and as for: "No-one here is talking about advanced c++, we're talking modern c++." I am. Reconsider your examples in ternms of not just whether someone needs the improvement, but also whether someone actually needs the preceding alternative you are complaining about.
  - maccard 5y ago
    > Your examples might fit the discussion better if you made unreadable C++03 code that worked. I deliberately made it not work - calling cend instead of end fixes the issue (one which isn't possible possible the range based loops) > Your second one hides almost everything from me. If the second one fails to compile and gives me a paragraph-long encrypted complaint, I need to somehow half-comment the thing out and create a bunch of test code so I can go in the debugger and figure out what you are actually doing. And I disagree here. In practice the only issue I've ever seen with range based for loops at compile time is no iterator support. The error on clang and msvc is incredibly clear here. Chances are the compiler error message about comparing a const iterator to a non const iterator is going to be more obtuse > also whether someone actually needs the preceding alternative you are complaining about. I cannot think of a _single_ situation where the NULL macro is required where nullptr wouldn't be an improvement. I'm not saying don't use the fundamental constructs when they're needed, I'm saying use the modern alternatives when they're suitable. Unique_ptr and move semantics alone eliminated practically every use after free bug I've seen in the last decade, for example. Enum class is another great example - legacy enums are absolutely chock full of foot guns and I have found countless bugs where someone just passes garbage through. Again those bugs just don't exist with the modern replacement.

dragonwriter 5y ago

> Even when programming in python, half the time I find myself switching to a simple loop over an index because I realize I need the index. If you need to iterate over an iterable xs and discover you need the index as well, in Python you shouldn't switch to a loop over the index, you should switch from: for x in xs: ... to: for idx, x in enumerate(xs): ...

maccard 5y ago

> How hard is it to read a "for" loop? for (std::unordered_map<std::string, int>::const_iterator it = some_map.cbegin();it != some_map.end(); ++it) is pretty damn unreadable (and for bonus points it doesn't compile) compared to for (const auto& keypair : some_map) Which doesn't have the possibility of the issue in the previous snippet (cbegin != end rather than cbegin != cend) > For many applications, advanced C++ is solving problems they don't have. No-one here is talking about advanced c++, we're talking modern c++. > The above poster mentioned audio. ... They only need a few simple pointers... And we all know that audio is immune from massive security vulnerabilities, right? [0] "New" features like nullptr (instead of NULL), unique_ptr, move semantics as examples can just flat out avoid classes of bugs that come up in low level programming, and features like constexpr and static assert can make runtime checks compile time checks instead. All these features can be escape hatched if you really really need to just cast to a void pointer to fill a buffer at the end, but the surface area for nasty bugs is significantly reduced if you do so. [0] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-41331 https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

simplestats 5y ago
Your examples might fit the discussion better if you made unreadable C++03 code that worked. But nonetheless, I don't agree. I can directly read what your first attempt at a loop is trying to do. Your second one hides almost everything from me. If the second one fails to compile and gives me a paragraph-long encrypted complaint, I need to somehow half-comment the thing out and create a bunch of test code so I can go in the debugger and figure out what you are actually doing. Are you saying the creation of security vulnerabilities has decreased in the last ten years. edit: and as for: "No-one here is talking about advanced c++, we're talking modern c++." I am. Reconsider your examples in ternms of not just whether someone needs the improvement, but also whether someone actually needs the preceding alternative you are complaining about.
- maccard 5y ago
  > Your examples might fit the discussion better if you made unreadable C++03 code that worked. I deliberately made it not work - calling cend instead of end fixes the issue (one which isn't possible possible the range based loops) > Your second one hides almost everything from me. If the second one fails to compile and gives me a paragraph-long encrypted complaint, I need to somehow half-comment the thing out and create a bunch of test code so I can go in the debugger and figure out what you are actually doing. And I disagree here. In practice the only issue I've ever seen with range based for loops at compile time is no iterator support. The error on clang and msvc is incredibly clear here. Chances are the compiler error message about comparing a const iterator to a non const iterator is going to be more obtuse > also whether someone actually needs the preceding alternative you are complaining about. I cannot think of a _single_ situation where the NULL macro is required where nullptr wouldn't be an improvement. I'm not saying don't use the fundamental constructs when they're needed, I'm saying use the modern alternatives when they're suitable. Unique_ptr and move semantics alone eliminated practically every use after free bug I've seen in the last decade, for example. Enum class is another great example - legacy enums are absolutely chock full of foot guns and I have found countless bugs where someone just passes garbage through. Again those bugs just don't exist with the modern replacement.