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. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev