220 17569 article Path: news.gmane.org!not-for-mail From: "dgutson ." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: explicit[ly] require initialization of attributes Date: Wed, 29 Apr 2015 15:57:21 -0300 Lines: 114 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1430333852 2261 80.91.229.3 (29 Apr 2015 18:57:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 18:57:32 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDE3NBMV6UFBBEWTQSVAKGQESUEVMKA@isocpp.org Wed Apr 29 20:57:25 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YnXAh-0003DN-Ss for gclcip-std-proposals@m.gmane.org; Wed, 29 Apr 2015 20:57:24 +0200 Original-Received: by obblk5 with SMTP id lk5sf42571380obb.2 for ; Wed, 29 Apr 2015 11:57:22 -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:date:message-id:subject:from:to :content-type:content-transfer-encoding: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=i2qu4ytDK1d432qwwXiwYpZtbZ8tJoeCxYqXvY+3iOk=; b=iZdcaQrlaUG1bdafnU/hlWcbAemQPaNhtHJWJDhPFGfFP6aAbhnx9Sf/+usPKzxIqh 4uuLJ9oiqI1e3QO9iWt6wADiCR78t/YE2uDtfsvnVRxx8p2Z8BJI5zrc5Zdy7zFBK8t3 FEr0PCjm26995QuYZ84bpLba/4aYL/6GPjxr1/yvG0cpD55CYt1Vaj/oRiZDo21Rqltc eElxyVQjgUwJaOVtIrC11Yo/Q60aNAZaGrp99equD6HYl5019vy0Nf7spMKMCgKrkU+e c7Q2dIjYOOLr4R5Wt0mhTRb0cG8kCUyZTG3lodEAcFSnTjbKZifaGrpQBUNOti99vhnz lPZQ== X-Gm-Message-State: ALoCoQle56h9yTsgwXfs/bwwyFfVtle+oqMyDgtg9sPt8yhkCf/ooX9/iUeCmfGnXDbsRoYy0t3o X-Received: by 10.182.120.5 with SMTP id ky5mr779511obb.21.1430333842865; Wed, 29 Apr 2015 11:57:22 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.1.1 with SMTP id 1ls645480igi.31.gmail; Wed, 29 Apr 2015 11:57:22 -0700 (PDT) X-Received: by 10.107.7.196 with SMTP id g65mr744891ioi.28.1430333842209; Wed, 29 Apr 2015 11:57:22 -0700 (PDT) Original-Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com. [2607:f8b0:4001:c03::233]) by mx.google.com with ESMTPS id l74si628412iol.61.2015.04.29.11.57.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 11:57:22 -0700 (PDT) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:4001:c03::233 as permitted sender) client-ip=2607:f8b0:4001:c03::233; Original-Received: by iedfl3 with SMTP id fl3so56138715ied.1 for ; Wed, 29 Apr 2015 11:57:21 -0700 (PDT) X-Received: by 10.42.119.2 with SMTP id z2mr5028044icq.1.1430333841753; Wed, 29 Apr 2015 11:57:21 -0700 (PDT) Original-Received: by 10.36.55.5 with HTTP; Wed, 29 Apr 2015 11:57:21 -0700 (PDT) X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:4001:c03::233 as permitted sender) smtp.mail=danielgutson@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.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: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:17569 Archived-At: 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. --=20 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? --=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/. .