Re: [006/nnn] poly_int: tree constants

[Martin Sebor <msebor@gmail.com>]

On 10/26/2017 12:05 PM, Pedro Alves wrote:
> 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.

You're by far not alone, but it's a shrinking camp as
the majority have come to appreciate the benefits of the practice.
You can see it reflected in most popular coding standards, including
the CERT C++ Secure Coding Standard, Google C++ Style Guide, Sutter
and Alexandrescu's C++ Coding Standards, Scott Meyer's books, and
so on.  Just like with every rule, there are exceptions, but there
should be no doubt that in the general case, it is preferable to
declare each variable at the point where its initial value is known
(or can be computed) and initialize it on its declaration.

>> 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. :-)

That would make sense to me and from the sound of some of his
comments also Richard's preference.

Martin