> proof that the person saying that does not understand the C++ language. This was followed by several "I am a C++ standard library implementer and everyone I know calls it the STL". Things deteriorated from there.
It feels natural to assume that the implementers and long time WG21 members must understand the language, but this is not true. C++ spiralled well beyond the capability of a person to actually understand it years ago.
Maybe that's unfair, but it's unusual. This is a constructed language, its syntax and semantics matter greatly and yet in practice our grasp of its meaning is more akin to that for say, English, than for Perl or Rust.
There are contradictory style guides, people with well meant rules of thumb contradicted by a world of real usage, numerous dialects, not to mention people who strongly believe other users of the language are "doing it wrong" and yet what they're doing works fine.
> The post got linked by Hackernews and Reddit. As is usual the majority of comments did not talk about the actual content but instead were focused on two tangential things.
Too true, and this is too good. Start with part 1 (and the comments) if you haven’t.
Python iterators are simple, but also less capable, for example you cannot easily modify a container using them.
In C++ this is equivalent to an InputIterator.
I’ve said it many times: a pure C++20 standard library imagined from first principles with total disregard for legacy code would do amazing things for the reputation and value of C++ as a language. It could be so much better than it is.
Yes, I understand, compatibility. At some point, clean new code bases should not be burdened with that albatross.
> Sadly there is not a simple way to integrate this to native loop constructs without macros and even then it is a bit ugly.
I’ve implemented something like this before, without macros. It’s a little ugly, but not that bad IMO.
If you write a native range-based for loop:
it essentially desugars to To make it work with a custom type, you need to implement `begin()` and `end()` methods, but the returned objects don’t need to support the full STL iterator protocol; they only need to support the exact sequence of operations from the desugaring. So, for example, `end()` can return a unique `End` type that contains no data and does nothing. `begin()` can return a different type that does all the real work and implements `operator!=(End)`. With that, it’s not too hard to implement a wrapper around a Python-like iterator protocol.The main drawback is that you need to temporarily store each item in the begin object before it’s moved into the iteration variable. This is because you have to already know whether a next item exists at the point of `it != end`, but then the item isn’t actually retrieved until `*it`. The extra move has a slight cost, but the compiler can often optimize it away to nothing. You can also avoid this if the for loop uses a reference type (`for (auto& foo : obj)`).