On 10/26/2017 05:37 PM, Martin Sebor wrote: > I agree that the latter use case is more common in GCC, but I don't > see it as a good thing. GCC was written in C and most code still > uses now outdated C practices such as declaring variables at the top > of a (often long) function, and usually without initializing them. > It's been established that it's far better to declare variables with > the smallest scope, and to initialize them on declaration. Compilers > are smart enough these days to eliminate redundant initialization or > assignments.
I don't agree that that's established. FWIW, I'm on the "prefer the -Wuninitialized" warnings camp. I've been looking forward to all the VRP and threader improvements hoping that that warning (and -Wmaybe-uninitialized...) will improve along. > My comment is not motivated by convenience. What I'm concerned > about is that defining a default ctor to be a no-op defeats the > zero-initialization semantics most users expect of T(). This sounds like it's a problem because GCC is written in C++98. You can get the semantics you want in C++11 by defining the constructor with "= default;" : struct T { T(int); // some other constructor forcing me to // add a default constructor. T() = default; // give me default construction using // default initialization. int i; }; And now 'T t;' leaves T::i default initialized, i.e., uninitialized, while T() value-initializes T::i, i.e., initializes it to zero. So if that's a concern, maybe you could use "= default" conditionally depending on #if __cplusplus >= C++11, so that you'd get it for stages after stage1. Or just start requiring C++11 already. :-) Thanks, Pedro Alves