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

Alex Rousskov rousskov at measurement-factory.com
Fri Sep 30 17:10:47 UTC 2016


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?


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

Alex.



More information about the squid-dev mailing list