Note: Objecting to the term “invalid iterator” for “iterator that points one past the end of an array that results in OOB access if you dereference it” is not a valid defense of C++.
-
-
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Every time I see stuff like this makes me hate C++ more. Maybe I'm wrong but it feels like this would be less likely to happen without abstractions making it "look safe".
-
Not really. It was a debug mode assert that should have been a runtime if check. It’s not about abstractions here.
- 5 more replies
New conversation -
-
-
this isn't C++ iterator invalidation, this is unchecked out of bounds access, which is also solved by Rust in a way that could be solved in C++, but isn't because unchecked-by-default is friggin stupid
-
i.e., this is solved by `operator*` and `operator[]` checking for OOB in the library, not by adding a borrow checker
- 2 more replies
New conversation -
-
-
I don’t know if I’d call it iteration invalidation if the iterator was never valid. Definitely related, but could hypothetically be solved if the API just used an optional type, without needing a borrow checker.
-
This Tweet is unavailable.
New conversation -
-
-
read the bug report. They had a check enabled only in debug mode. The renderer process (not thread) can be made to pick an invalid id and therefore return an invalid iterator.
- 1 more reply
New conversation -
This Tweet is unavailable.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.