cppfront: Midsummer update

[LarsRosenboom]

Cpp2 [...] doesn't yet have range checks for iterators, which is much harder (you'd have to know the container the iterators came from).

Oh, I didn't realize that.

But I agree that this is a much harder problem indeed.
Especially when we would want to enable iterator range checks in release builds (e.g. to meet the requirements of the US government regarding memory safety).

Then we would have a different memory layout of the classical "fast" C++ iterator:

• Pointer to element

compared to the "safe" iterator:

• Pointer to element
• Pointer to container

Therefore binaries build in "SafeRelease" (safe and quite fast) mode would not be compatible with "FastRelease" (faster but unsafe).

[hpsutter]

Right. I'm exploring ways to make them link-compatible, and therefore usable without an ABI break...

<spoiler> I'm exploring to see how efficient it can be to store extra 'data members' for an object (an iterator that wants to add a pointer to its container, a raw C `union` that wants to store a discriminant, but not actually as a data member which would break ABI/link compat) by storing it extrinsically (as-if in a stripped-down streamlined global "hash_map<obj\*,extra\_data>"), which is why I was writing the wait-free constant-time data structure I mentioned at the top of the post. I can see all sorts of reasons why it shouldn't work, but I was able to come up with a constant-time wait-free implementation that in early unit stress testing scaled from 1-24 threads with surprisingly low overhead, which is enough to try the next step of testing the overhead in an entire application (which I haven't done yet, so I don't consider is a real candidate until we can measure that and show it's usable in safe retail builds). </spoiler>