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