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

[Alex Rousskov]

On 09/30/2016 10:55 PM, Amos Jeffries wrote:
> 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.

Unfortunately, I see no correlation between my question and your
response. Dropping the topic as not important enough to continue this
discussion. Thus, no new rules [for the new/changed code] for now.

Alex.