3 ms·
zabzonk said "if a type has a constructor", but I don't think the int type does, which is why you get uninitialized memory here. Any instance of Foo will run F
by munificent 3y ago
zabzonk said "if a type has a constructor", but I don't think the int type does, which is why you get uninitialized memory here.
Any instance of Foo will run Foo's constructor because Foo has one. The problem is that that instance of Foo won't definitely have x initialized, because int doesn't.
- UncleMeat 3y agoSure. If for some reason you only care about this with regards to struct types that have constructors that correctly initialize all of their members then you are good by default (sort of, there are weird edge cases here with globals). But "safe for this, not for that" is not especially compelling to me when it is hard to imagine a C++ codebase that doesn't use primitives/pod types somewhere. Plus, there are stl types that don't guarantee initialization of members. So it isn't like only ever resting on top of stl types is sufficient. std::optional has a non-default constructor but it can happily blow up because of a read of uninitialized data. And the fact that this is the silent default behavior in C++ is wild to me. Even in languages where it is possible to leave data in an uninitialized state, you should need to loudly signal it.
- munificent 3y ago> And the fact that this is the silent default behavior in C++ is wild to me. I agree, totally. Backwards compatibility is a cruel mistress.