220 14879 <991368986-1417873941-cardhu_decombobulator_blackberry.rim.net-220778910-@b2.c5.bise6.blackberry> article Path: news.gmane.org!not-for-mail From: "Daniel Gutson" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Safer C++: never allow implicitly uninitialized variables? Date: Sat, 6 Dec 2014 13:52:21 +0000 Lines: 155 Approved: news@gmane.org Message-ID: <991368986-1417873941-cardhu_decombobulator_blackberry.rim.net-220778910-@b2.c5.bise6.blackberry> References: <4720a9a6-24d5-4488-a229-2bdf2433fa03@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="part4163-boundary-1529832253-1049971132" X-Trace: ger.gmane.org 1417873953 2064 80.91.229.3 (6 Dec 2014 13:52:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Dec 2014 13:52:33 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDE3NBMV6UFBBGEURSSAKGQE3W4H7SA@isocpp.org Sat Dec 06 14:52:26 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XxFmc-00034C-6g for gclcip-std-proposals@m.gmane.org; Sat, 06 Dec 2014 14:52:26 +0100 Original-Received: by mail-pa0-f70.google.com with SMTP id lj1sf15145536pab.1 for ; Sat, 06 Dec 2014 05:52:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:references:in-reply-to :sensitivity:importance:subject:to:from:date:content-type :mime-version:x-original-sender:x-original-authentication-results :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=l88S+MhO67XnJ6KJ8mDo0GQPgWFzR0PuiQEFHQYe/zs=; b=aDoJNPNDupf7LJgr4Plk5CXRoA9fM95K42V0pbPbEnsjP70oEIIDOmdhwYoDRlhZqB myIOzLvAWbwZ5oSPWUiYipicgITaydNs+yhM4+ECetcyA/dMogWpuZ6sWy01gOEi5v09 1D4NoSiQZPaBAoW/H/7m46ffOITWI9EdDkTmFnVGwpjq7PEJIdLVNKOZinBPlbtYurh0 YZuBpcY8scbf3fFNU1k5Ik8xOTPdZPRjPPw13aNwQjo8AbZGB7P/COS/lbxoNPpaj/J7 dmj/m8ROgaXSXaU2WNzPpAbeFldGF6rOfMQeYiuWM65sHzZi2jQytYROcyu8IFwZLoRL 8nOg== X-Gm-Message-State: ALoCoQl6Qta3iPAuebHr3jtrIsLuqeAW6OZNJJRFXk6ROQU8enry2T2jEY8Eflm5GT9vc3NBK076 X-Received: by 10.66.182.7 with SMTP id ea7mr18219130pac.23.1417873945093; Sat, 06 Dec 2014 05:52:25 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.40.18 with SMTP id o18ls1465832ioo.10.gmail; Sat, 06 Dec 2014 05:52:24 -0800 (PST) X-Received: by 10.50.21.99 with SMTP id u3mr7167251ige.43.1417873944322; Sat, 06 Dec 2014 05:52:24 -0800 (PST) Original-Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com. [2607:f8b0:4001:c03::232]) by mx.google.com with ESMTPS id 129si18454414ion.77.2014.12.06.05.52.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Dec 2014 05:52:24 -0800 (PST) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:4001:c03::232 as permitted sender) client-ip=2607:f8b0:4001:c03::232; Original-Received: by mail-ie0-f178.google.com with SMTP id tp5so2251463ieb.23 for ; Sat, 06 Dec 2014 05:52:24 -0800 (PST) X-Received: by 10.42.38.133 with SMTP id c5mr19524362ice.26.1417873943968; Sat, 06 Dec 2014 05:52:23 -0800 (PST) Original-Received: from 172.29.198.177 (bda-74-82-81-60.bis6.us.blackberry.com. [74.82.81.60]) by mx.google.com with ESMTPSA id ck1sm824405igb.0.2014.12.06.05.52.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 06 Dec 2014 05:52:23 -0800 (PST) X-rim-org-msg-ref-id: 991368986 X-Priority: Normal In-Reply-To: <4720a9a6-24d5-4488-a229-2bdf2433fa03@isocpp.org> Sensitivity: Normal Importance: Normal 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::232 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:14879 Archived-At: --part4163-boundary-1529832253-1049971132 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 By initializing variables with an arbitrary (initial) value (which may not = make sense in the semantic of your application), you are only adding perfor= mance overhead, whereas usage of uninitialized variables can already be det= ected in most cases by stating checking of most toolchains/static detection= tools. If your compiler doesn't warn you about such cases, ask your compiler vendo= r rather to try to change the std affecting the rest of people who uses mod= ern compilers or checkers. I suggest you to use lint-like tools and enable all the warnings of your co= mpiler. Daniel. -----Original Message----- From: Germ=C3=A1n Diago Date: Fri, 5 Dec 2014 22:10:24=20 To: Reply-To: std-proposals@isocpp.org Subject: [std-proposals] Safer C++: never allow implicitly uninitialized va= riables? Hello everyone, I wonder if it would make sense to make variables in C++ automatically=20 value-initialized or there would be problems. Since we are making c++ safer and safer, would it make sense to do the=20 following? int a; //value-initialized to 0 Later, some syntax like in D language could be provided: int a =3D void; The rationale behind this change would be: - an uninitialized variable that is replaced by these new semantics does=20 not produce incorrect behaviour. - makes the language safer to use. In the case where performance must be preserved, a compiler option with the= =20 old semantics would be enough. Would this make any sense or I am missing manu points? It looks to me that= =20 this could be backwards-compatible and the noly thing that could happen is a performance bug, which can be=20 solved replacing iniitialization or by a compiler switch for large codebases. --=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/. --=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/. --part4163-boundary-1529832253-1049971132 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 <= meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type">By initializing variables with an arbitrary (initial) value (whic= h may not make sense in the semantic of your application), you are only add= ing performance overhead, whereas usage of uninitialized variables can alre= ady be detected in most cases by stating checking of most toolchains/static= detection tools.
If your compiler doesn't warn you about such cases, a= sk your compiler vendor rather to try to change the std affecting the rest = of people who uses modern compilers or checkers.
I suggest you to use l= int-like tools and enable all the warnings of your compiler.

Dan= iel.
From: Germ=C3=A1n Diago <germandiago@gmail.com>
Date: Fri, 5 Dec 2014 22:10:24 -0800 (PST)
T= o: <std-proposals@isocpp.org>
ReplyTo: std-prop= osals@isocpp.org
Subject: [std-proposals] Safer C++: never allow implicitl= y uninitialized variables?

Hello ever= yone,

I wonder if it would make sense to make variables = in C++ automatically value-initialized or there would be problems.

Since we are making c++ safer and safer, would it make sen= se to do the following?


int a; //va= lue-initialized to 0

Later, some syntax like in D = language could be provided:

int a =3D void;
<= div>

The rationale behind this change would be= :

- an uninitialized variable that is replaced by = these new semantics does not produce incorrect behaviour.
- makes= the language safer to use.

In the case where perf= ormance must be preserved, a compiler option with the old semantics would b= e enough.

Would this make any sense or I am missin= g manu points? It looks to me that this could be backwards-compatible
=
and the noly thing that could happen is a performance bug, which can b= e solved replacing iniitialization or by a
compiler switch for la= rge codebases.



--

---
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>.

--

---
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>.
--part4163-boundary-1529832253-1049971132-- .