[squid-dev] [PATCH] polish Config2 using C++11 features

[Amos Jeffries]

On 1/10/2016 6:10 a.m., Alex Rousskov wrote:
> On 09/30/2016 10:58 AM, Amos Jeffries wrote:
>> On 1/10/2016 5:09 a.m., Alex Rousskov wrote:
>>> On 09/30/2016 09:38 AM, Amos Jeffries wrote:
>>>> So I think we can start using these to replace old C-style
>>>> initialization and clear() functions.
> 
>>> Agreed. I wonder whether we should be consistent -- if some class data
>>> members cannot use default initialization and some can, should we
>>> initialize _all_ members in the constructor(s)?
> 
>> I was aiming towards that some years ago. But reality turned out to be
>> that some of the bigger classes had annoyingly long lists of members to
>> initialize, many of which did not exactly need it. And no compiler or
>> static checking detects patches that forget to set one if it was a
>> complex class with own default constructor (like our Pointer types,
>> which were frequently missed).
> 
> Sorry I was not clear. I was not proposing a one-size-fits-all approach
> that you were trying to enforce some years ago. The consistency I was
> talking about has a single class scope. In other words:
> 
> * If, for a specific class C, some C members cannot use default
> initializers, then none of the C members should use default initializers.
> 
> Is that a good rule? Do we need a rule here?

What we have now is to do the work to cleanly and properly avoid
uninitialized members on the build testing. But to treat other members
which handle themselves as optionally initialized.

That is sufficient, automatically testable (-Wuninitialized), and can be
applied as a blanket rule instead of trying to remember where its used
and where not.

If one wishes to go around adding needless entries to constructor lists,
one is free to do so. But it is really pointless work and wasted lines
of code.

> 
>> So these days I'm only setting the basic POD type members explicitly on
>> construct. If we can set them like this and skip defining a default
>> constructor entirely that would be even better for shrinking the code.
> 
> Sure, but the consistency I am worried about is about a different case
> where we cannot avoid defining a constructor because some members
> require non-constexpr initializers.

In that case it is optional whether the code explicitly says what the
compiler will do anyway.

We might be pushed into that position by "Big 3" or "Big 5"
requirements. But as optional we can deal with all them case-by-case.

Amos