220 17575 article Path: news.gmane.org!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: explicit[ly] require initialization of attributes Date: Wed, 29 Apr 2015 13:09:39 -0700 Lines: 309 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113df4141ca8890514e28f54 X-Trace: ger.gmane.org 1430338183 11592 80.91.229.3 (29 Apr 2015 20:09:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 20:09:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCGNLO5F34OBBBHVQSVAKGQESQ5DOBQ@isocpp.org Wed Apr 29 22:09:43 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YnYIf-0002jz-Oo for gclcip-std-proposals@m.gmane.org; Wed, 29 Apr 2015 22:09:42 +0200 Original-Received: by yhik52 with SMTP id k52sf27232152yhi.1 for ; Wed, 29 Apr 2015 13:09:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=Cd1SZgWnTUZiZHMQJ5lPJho00NXV7tZnP7besljDqyo=; b=csjgf5L2nus/WA3vcNr84Yh9PDJlEpF1sPrwf0DgpS7atNe9tq87rcUZtbRzw0NTg2 SjwwaewwC9E9dyzAYj8n1hghpodXKNhieSxEumWRJC4Z5QW8lzAnZROhGYwMs6OLYoJ7 zh6XWxaalOZAGioPmd7dW7v7LDD4VduTmddj5C/AEns3b/rG7dZ3Er5ZBqeqz6fXtaGM cwSwgQ3xPraxVxXkXLMbC+XKJtR7F+QkZsBPUKe5LyLXWCd7+DQJRE1SXryU9KhUJssP f/Sw49jVJiDwJ8JPo7l/OnLMc20USzmMVZe5Gv58ixaGx8q+2gOmMvHRBzuMjZKkuAub Ca+Q== X-Gm-Message-State: ALoCoQneOZUG0MfGr5PgJTcQ6H/CL3l32LqPUi6xCdiSHm8HNKTtAMSz4mg9T3hQpygI/8HEtJQB X-Received: by 10.236.62.225 with SMTP id y61mr1223968yhc.29.1430338180604; Wed, 29 Apr 2015 13:09:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.96.234 with SMTP id dv10ls378519obb.3.gmail; Wed, 29 Apr 2015 13:09:39 -0700 (PDT) X-Received: by 10.202.189.134 with SMTP id n128mr664216oif.42.1430338179975; Wed, 29 Apr 2015 13:09:39 -0700 (PDT) Original-Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com. [2607:f8b0:4003:c06::236]) by mx.google.com with ESMTPS id pm9si68806oeb.0.2015.04.29.13.09.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 13:09:39 -0700 (PDT) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c06::236 as permitted sender) client-ip=2607:f8b0:4003:c06::236; Original-Received: by oiko83 with SMTP id o83so31367964oik.1 for ; Wed, 29 Apr 2015 13:09:39 -0700 (PDT) X-Received: by 10.202.211.129 with SMTP id k123mr613437oig.43.1430338179725; Wed, 29 Apr 2015 13:09:39 -0700 (PDT) Original-Received: by 10.60.166.78 with HTTP; Wed, 29 Apr 2015 13:09:39 -0700 (PDT) In-Reply-To: X-Original-Sender: calabrese@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c06::236 as permitted sender) smtp.mail=calabrese@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , X-Original-From: Matt Calabrese Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:17575 Archived-At: --001a113df4141ca8890514e28f54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can't this be done with C++11 attributes? It could just be a datamember attribute that requires that member to be explicitly constructed. It would be something like [[explicit_construction]] and would suggest that the compiler emits a diagnostic if the member is not explicitly initialized. I'm not a fan of the template approach because it changes the type of the datamember and requires indirect access through the new datamember type (i.e. via a get() accessor), all simply because we want the member to be explicitly initialized. If this is really a desired feature, I think it makes more sense as an in-language specifier/attribute. On Wed, Apr 29, 2015 at 11:57 AM, dgutson . wrote: > I think I've seen this. > > Problem: > - when adding a new ctor, a programmer may inadvertently leave > uninitialized attributes (specially PODs). Similarly, when adding a > new attribute, a programmer may forget to call its ctor (or initialize > it) in all the ctors of the class (again, specially when the new > attribute is a POD). > > Problem Example1: > > //before the change: > struct S > { > int x; > S(/*some signature*/) : x(1) {} > }; > > //after the change: > struct S > { > int x; > S(/*some signature*/) : x(1) {} > S(/*some OTHER signature*/) {} // x is uninitialized > }; > > Problem Example 2: > //before the change: > struct S > { > int x; > S(/*some signature*/) : x(1) {} > }; > > //after the change: > struct S > { > int x; > int y; // new attribute > S(/*some signature*/) : x(1) {} // y is uninitialized > }; > > - Why this problem is important? > The more attributes / ctors the class has, the problem gets worse > (though that might be caused by a bad design of poor modularization). > The problem is relevant when writing maintainable code, since > future maintainers may incur in the errors mentioned above. > > - How people is working around this issue nowadays? > There are both static checkers and dynamic checkers (such as > valgrind) that may detect use of uninitialized data. > People can =3Ddelete the default ctor of the contained objects. > > - Alternative proposed solutions > Solution 1: library approach. Provide a type wrapper without a > default ctor (such as initialization_required). Such wrapper could > be implemented extending the template type (inheriting from it) and > removing the default ctor, and should be template-specialized for PODs > with all the operations of each POD. > > struct S > { > initialization_required x; > initialization_required y; > S(/*some signature*/) : x(1) {} // error: y initialization missing > }; > > Solution 2: prefix the attribute declaration with some keyword > (such as "explicit"). > > struct S > { > explicit int x; > explicit int y; > S(/*some signature*/) : x(1) {} // error: y is uninitialized > }; > > - Discussion: what happens with inheritance? > As mentioned above, this problem gets relevant with PODs so > inheritance wouldn't apply in that case (unless we propose the ability > to extend from PODs some day ;-) ). > Nevertheless, both solutions could be applicable to inheritance: > > Sol1: struct S : initialization_required { ... }; > Sol2: struct S : explicit T { ... }; > > Ideas? Is this worth to write a formal proposal? > > Thanks, > > Daniel. > > > > -- > Who=E2=80=99s got the sweetest disposition? > One guess, that=E2=80=99s who? > Who=E2=80=99d never, ever start an argument? > Who never shows a bit of temperament? > Who's never wrong but always right? > Who'd never dream of starting a fight? > Who get stuck with all the bad luck? > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --001a113df4141ca8890514e28f54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can't this be done with C++11 attributes? It could jus= t be a datamember attribute that requires that member to be explicitly cons= tructed. It would be something like [[explicit_construction]] and would sug= gest that the compiler emits a diagnostic if the member is not explicitly i= nitialized.

I'm not a fan of the template approach b= ecause it changes the type of the datamember and requires indirect access t= hrough the new datamember type (i.e. via a get() accessor), all simply beca= use we want the member to be explicitly initialized. If this is really a de= sired feature, I think it makes more sense as an in-language specifier/attr= ibute.

On Wed, Apr 29, 2015 at 11:57 AM, dgutson . <danielgutson@gmail.com= > wrote:
I think I've s= een this.

Problem:
=C2=A0 - when adding a new ctor, a programmer may inadvertently leave
uninitialized attributes (specially PODs). Similarly, when adding a
new attribute, a programmer may forget to call its ctor (or initialize
it) in all the ctors of the class (again, specially when the new
attribute is a POD).

Problem Example1:

//before the change:
struct S
{
=C2=A0 =C2=A0 int x;
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {}
};

//after the change:
struct S
{
=C2=A0 =C2=A0 int x;
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {}
=C2=A0 =C2=A0 S(/*some OTHER signature*/) {} // x is uninitialized
};

Problem Example 2:
//before the change:
struct S
{
=C2=A0 =C2=A0 int x;
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {}
};

//after the change:
struct S
{
=C2=A0 =C2=A0 int x;
=C2=A0 =C2=A0 int y; // new attribute
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {} // y is uninitialized
};

- Why this problem is important?
=C2=A0 =C2=A0 The more attributes / ctors the class has, the problem gets w= orse
(though that might be caused by a bad design of poor modularization).
=C2=A0 =C2=A0 The problem is relevant when writing maintainable code, since=
future maintainers may incur in the errors mentioned above.

- How people is working around this issue nowadays?
=C2=A0 =C2=A0 There are both static checkers and dynamic checkers (such as<= br> valgrind) that may detect use of uninitialized data.
=C2=A0 =C2=A0 People can =3Ddelete the default ctor of the contained object= s.

- Alternative proposed solutions
=C2=A0 =C2=A0Solution 1: library approach. Provide a type wrapper without a=
default ctor (such as initialization_required<T>). Such wrapper could=
be implemented extending the template type (inheriting from it) and
removing the default ctor, and should be template-specialized for PODs
with all the operations of each POD.

struct S
{
=C2=A0 =C2=A0 initialization_required<int> x;
=C2=A0 =C2=A0 initialization_required<int> y;
=C2=A0 =C2=A0S(/*some signature*/) : x(1) {} // error: y initialization mis= sing
};

=C2=A0 =C2=A0Solution 2: prefix the attribute declaration with some keyword=
(such as "explicit").

struct S
{
=C2=A0 =C2=A0 explicit int x;
=C2=A0 =C2=A0 explicit int y;
=C2=A0 =C2=A0 S(/*some signature*/) : x(1) {} // error: y is uninitialized<= br> };

=C2=A0- Discussion: what happens with inheritance?
=C2=A0 =C2=A0 =C2=A0As mentioned above, this problem gets relevant with POD= s so
inheritance wouldn't apply in that case (unless we propose the ability<= br> to extend from PODs some day ;-) ).
=C2=A0 =C2=A0 =C2=A0Nevertheless, both solutions could be applicable to inh= eritance:

Sol1:=C2=A0 =C2=A0struct S : initialization_required<T> { ... };
Sol2:=C2=A0 =C2=A0struct S : explicit T { ... };

Ideas? Is this worth to write a formal proposal?

Thanks,

=C2=A0 =C2=A0 Daniel.



--
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-propo= sals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/gro= up/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a113df4141ca8890514e28f54-- .