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.

> 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.

I could be wrong but all the fancy stuff you are doing to impose constants, including your bug, look like c++11 to me.

Without these the complexity in your example disappears, and every word has direct intuitive meaning. Except for the ugly type expression on the left (which is kind of thing one must love if you endeavored to be a C++ programmer in the first place, though personally I do agree it's increasingly hard to read beyond the most basic cases). Nonetheless, using auto is the cause of the problem I was referring to. This eliminates the remaining half of the ugliness, but now if the code inside the loop chokes in your inputs, I have no idea why. Maybe if I'm lucky the compiler will give me a paragraph that I can try to parse descriing the mess that the object was compiled into, or maybe it will just say "Can't find a suitable template. Have a nice day".

Your loop body code is choking probably because you have imagined that the loop induction variable is still an iterator. It's not. It is a direct reference to a container element. So, keypair.second, not it->second.