3 ms·

i said "if a type has a constructor". but if you are fiddling around with ints and chars and the like, then you will need to initialise them. i have been writin

i said "if a type has a constructor". but if you are fiddling around with ints and chars and the like, then you will need to initialise them. i have been writing c++ since the mid80s and have never found this to be a problem, or at least no more than it would be to use an uninitialised int variable in C.

arcticbull 3y ago
The fact this is even a distinction anyone has to keep in mind is again an example of the problem. People are awful at remembering these weird little details. We shouldn't expect people do things they're bad at, all the time, and to get them right. And I'll go a step further and say we shouldn't let them by default. They should have to make it super explicit they want to opt into the weird behavior nobody expects. You can do this in Rust if you want! You just have to use unsafe { mem::uninitialized() } or even better, the newer unsafe { mem::MaybeUninit::uninit() } The whole point is that you probably don't ever want to have an uninitialized variable you can access willy-nilly, and if you do, you should be very explicit. Even your statement about C (and C++) isn't quite accurate, right, because anything static is guaranteed to be initialized to zero on creation. So while `int x` is a free for all, `static int x` is gonna be zero. Another thing people shouldn't have to think about! Principle of least surprise.
- zabzonk 3y ago
  i don't actually use ints much in my c++ code. iterators for looping over things. using ints for accumulating is a problem in most languages.
  - deleted 3y ago
    [deleted]
- BenFrantzDale 3y ago
  I agree. I wish we had to say `int x = std::uninitialized;`
UncleMeat 3y ago
"In some cases you are safe in other cases you aren't" is not good enough for real safety. Congrats if you never write bugs. For the rest of us, we will use the widely available data that demonstrates that these bugs recur over and over and over and over even in organizations with strong developers, strong testing culture, and where the use of static analyzers and fuzzing is widespread. Yes, C also has these problems. Both C and C++ represent significant safety risks, despite powering some of our absolute most security critical applications (the linux kernel and our web browsers). Other languages don't give you these footguns.

arcticbull 3y ago

The fact this is even a distinction anyone has to keep in mind is again an example of the problem. People are awful at remembering these weird little details. We shouldn't expect people do things they're bad at, all the time, and to get them right. And I'll go a step further and say we shouldn't let them by default. They should have to make it super explicit they want to opt into the weird behavior nobody expects. You can do this in Rust if you want! You just have to use unsafe { mem::uninitialized() } or even better, the newer unsafe { mem::MaybeUninit::uninit() } The whole point is that you probably don't ever want to have an uninitialized variable you can access willy-nilly, and if you do, you should be very explicit. Even your statement about C (and C++) isn't quite accurate, right, because anything static is guaranteed to be initialized to zero on creation. So while `int x` is a free for all, `static int x` is gonna be zero. Another thing people shouldn't have to think about! Principle of least surprise.

zabzonk 3y ago
i don't actually use ints much in my c++ code. iterators for looping over things. using ints for accumulating is a problem in most languages.
- deleted 3y ago
  [deleted]
BenFrantzDale 3y ago
I agree. I wish we had to say `int x = std::uninitialized;`

UncleMeat 3y ago

"In some cases you are safe in other cases you aren't" is not good enough for real safety. Congrats if you never write bugs. For the rest of us, we will use the widely available data that demonstrates that these bugs recur over and over and over and over even in organizations with strong developers, strong testing culture, and where the use of static analyzers and fuzzing is widespread. Yes, C also has these problems. Both C and C++ represent significant safety risks, despite powering some of our absolute most security critical applications (the linux kernel and our web browsers). Other languages don't give you these footguns.