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
