3 ms·
> it’s possible to write completely type and resource safe code in c++ now "It's possible" is a rather low bar. It's also "possible" in C. Is it easy though? I
by yakubin 6y ago
> it’s possible to write completely type and resource safe code in c++ now
"It's possible" is a rather low bar. It's also "possible" in C. Is it easy though? I wouldn't say so. Not if you push lambdas over queues to be invoked in another thread, or in the same thread, but later. Not if you take references to elements of std::vector. Not if you use std::vector<bool>. Not if you use operator[] on std::vector/std::array without tweaking some macros, because C++ committee in 2021 is still not convinced that bounds-checking is a reasonable default.
It's very easy on the other hand to write perfectly idiomatic "modern C++" which is memory-unsafe. Well... Easy if you figure out which one, among a dozen, is the right way™ to initialize a variable. (And then go and read code which initializes std::vector in all those different ways and try to guess which one does what.)
- rowanG077 6y agoIt's not that the comittee thinks bounds checking isn't a reasonable default. They can't change it because it will break existing code.
- gpderetta 6y agoIt will not break any valid program actually. I'm 97.5% sure that aborting or even throwing an exception on an out of bound vector::operator[] would be a fully conforming implementation. The fact is that most standard library implementations can already be easily configured to bound check, so there is little pressure to mandate this in the standard.
- yakubin 6y agoThe code, which would break, was already broken. Just in far worse ways than throwing exceptions: silent memory corruption. And there would be no backwards-compatibility breakage, since in cases, where it would throw, currently UB is triggered.
- andrewprock 6y agoThe existing code may be "broken" but it is making too much money to risk changing it for pedantic reasons.
- Koiwai 6y agoSimply do not compile them using -std=future then.