Sure, but you have to explicitly enable this feature. In c++ you can use the oldest shit from twenty years ago and your compiler happily does its job. All my c++ books are full of “you shouldn’t use xy as it is deemed unsafe now, but of course you still can”.
If a “safe C++” proposal truly proposes a safe subset, then yes your C++ code would have to opt-in to doing unsafe things. For the purposes of this discussion of a safe subset … the point is moot.
Rust still allows people to do (basically) whatever they want via unsafe blocks.
Yeah but I have written a lot of Rust and I have yet to use a single
unsafeblock.Saying “but… unsafe!” is like saying Python isn’t memory safe because it has
ctypes, or Go isn’t memory safe because of itsunsafepackage.You don’t have to use unsafe C++ functions either
C++ is technically safe if you follow best practices
The issue, to me, is that people learn older versions of the language first, and aren’t aware of the better ways of doing stuff.
IMO people should learn the latest C++ version first, and only look at the older types of implementation when they come across them
See my reply to funtrek’s reply.
Sure, but you have to explicitly enable this feature. In c++ you can use the oldest shit from twenty years ago and your compiler happily does its job. All my c++ books are full of “you shouldn’t use xy as it is deemed unsafe now, but of course you still can”.
If a “safe C++” proposal truly proposes a safe subset, then yes your C++ code would have to opt-in to doing unsafe things. For the purposes of this discussion of a safe subset … the point is moot.
It’s not moot. The Safe C++ is opt-in to safety. It has to be because otherwise it wouldn’t be compatible with existing C++.
That’s a laudable difference /s. Using Rust is also an “opt-in” option.