220 17570 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: explicit[ly] require initialization of attributes Date: Wed, 29 Apr 2015 22:12:13 +0300 Lines: 111 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: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1430334744 17780 80.91.229.3 (29 Apr 2015 19:12:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 19:12:24 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBDO2QSVAKGQEDAQYUDY@isocpp.org Wed Apr 29 21:12:16 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YnXP5-0006Ye-1X for gclcip-std-proposals@m.gmane.org; Wed, 29 Apr 2015 21:12:15 +0200 Original-Received: by oica37 with SMTP id a37sf46359026oic.1 for ; Wed, 29 Apr 2015 12:12:13 -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=gK6kA1aNxntiMSSnpT75207odbphP1fFmPhOHhMfEQA=; b=ACrsnWABEUwMutaA/Zq+wJaYml8RxA9SaFa6+IJwifmz4oVJXNA1wd38EqXmSmbGSk Gj8/DDHpwJBYvcvtgrRwC2XtmqeJA2CSZr4GWUpA9FIqSlWI4xpQ+3niCQ8mCG+rXE8l Fo0f+XOnm7BbGY8D62kA/kbcaucdNRUOTOI6t2KaJ6A+i7TIFlaBdFjbhtS7MRzhZrXO Y9oU4ep0EzZGaLk4tLT8SePCvjtJjVkQ46DELtjYOObm/wMtKjsRRXfxloJoOFpJ8JeW C+pvblz4SSVPmlvnMKPbPnyHl2HHnMo962BItidFMo+/Ym2eyZwLh8HQPftg92UKdyO/ CrOw== X-Gm-Message-State: ALoCoQkQth9j190w9pNAv+m7HOBkt1wZalpY5Io87JD9WoooLqrOYfLdwDs/+zOB9ygpCY5bNyi1 X-Received: by 10.182.80.7 with SMTP id n7mr971131obx.10.1430334733830; Wed, 29 Apr 2015 12:12:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.17.80 with SMTP id z77ls656577ioi.25.gmail; Wed, 29 Apr 2015 12:12:13 -0700 (PDT) X-Received: by 10.107.136.158 with SMTP id s30mr784950ioi.65.1430334733189; Wed, 29 Apr 2015 12:12:13 -0700 (PDT) Original-Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com. [2607:f8b0:4001:c03::22a]) by mx.google.com with ESMTPS id d20si62702ice.30.2015.04.29.12.12.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 12:12:13 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4001:c03::22a as permitted sender) client-ip=2607:f8b0:4001:c03::22a; Original-Received: by iedfl3 with SMTP id fl3so56522691ied.1 for ; Wed, 29 Apr 2015 12:12:13 -0700 (PDT) X-Received: by 10.50.35.195 with SMTP id k3mr30004717igj.11.1430334733086; Wed, 29 Apr 2015 12:12:13 -0700 (PDT) Original-Received: by 10.36.213.70 with HTTP; Wed, 29 Apr 2015 12:12:13 -0700 (PDT) In-Reply-To: X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4001:c03::22a as permitted sender) smtp.mail=ville.voutilainen@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:17570 Archived-At: On 29 April 2015 at 21:57, 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 =delete 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? Any particular reason why you're not using non-static data member initializers? That is, struct S { int x=42; int y=666; S(/*some signature*/) : x(1) {} // y is 666 since nothing else was provided }; You can make the NSDMI throw or even terminate if explicit initialization is not provided in a ctor-initializer. -- --- 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/. .