Not irony. I would very much like vector<T>::iterator to be T*. Keep it simple.
-
-
Replying to @ericniebler @joel_f and
I'm still thinking about a way to identify ContiguousIterator without tags...
1 reply 0 retweets 0 likes -
Replying to @Cor3ntin @ericniebler and
It's a runtime semantic requirement so tags are your only option. Just like input vs. forward iterators.
1 reply 0 retweets 0 likes -
Replying to @MalwareMinigun @ericniebler and
Something along the line of "convertible to T*"
2 replies 0 retweets 0 likes -
Replying to @Cor3ntin @ericniebler and
Okay but then you fail for vector and string iterators (and the like)
1 reply 0 retweets 0 likes -
Replying to @MalwareMinigun @Cor3ntin and
So I'm iterating a list while concatenating stuff onto the end of it...
2 replies 0 retweets 0 likes -
Replying to @TimSweeneyEpic @MalwareMinigun and
Hand wavy solution: perhaps the compiler should enforce not being able to call push_back when in a foreach loop over the vector
1 reply 0 retweets 0 likes -
Replying to @MikeNicolella @TimSweeneyEpic and
But there are plenty of situations where that's valid.
2 replies 0 retweets 0 likes -
Replying to @MalwareMinigun @TimSweeneyEpic and
That's why I said hand-wavy. I might be in support of an annotation on the loop that says "yes I know" or "use indexes instead of pointers" or something.
1 reply 0 retweets 0 likes -
Replying to @MikeNicolella @MalwareMinigun and
Compilers can't be expected to enforce "You can't do X here" for nontrivial X. Much easier in functional languages that are either pure or extended with carefully specified effects. E.g. Haskell iteration over IORef[t] forces you to specify exactly what's happening re mutation.
1 reply 0 retweets 2 likes
E.g. in Haskell, you'd have to say you're reading the list once then iterating over it and ignoring any changes made to the reference, or that you're reading it at each iteration to see if you're past the end. And then what to do if you write past the end after truncation.
-
-
Replying to @TimSweeneyEpic @MikeNicolella and
In contract, C++ is all hand-wavy about "don't do that while this other thing is happening, it's undefined behaviour". Which maybe one can live with in a little block of code, but it fails at the scale of big loops iterating global state and calling functions affecting it.
3 replies 0 retweets 3 likes -
Replying to @TimSweeneyEpic @MikeNicolella and
I don't disagree at all but at the same time maybe we also shouldn't write code like that?
0 replies 0 retweets 1 like
End of conversation
New conversation -
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.