220 11529 article Path: news.gmane.org!not-for-mail From: Krzysztof Ostrowski Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Controversy and debate: Uninitialized variables by default is a bug Date: Thu, 19 Jun 2014 09:33:52 -0700 (PDT) Lines: 410 Approved: news@gmane.org Message-ID: References: <60caa4ef-b32d-40fe-97b6-8918fbb2bd51@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_503_20055616.1403195632558" X-Trace: ger.gmane.org 1403195642 13286 80.91.229.3 (19 Jun 2014 16:34:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Jun 2014 16:34:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCGODRMA7YNBB4NBRSOQKGQELQJWCFQ@isocpp.org Thu Jun 19 18:33:55 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WxfHf-0006QR-41 for gclcip-std-proposals@m.gmane.org; Thu, 19 Jun 2014 18:33:55 +0200 Original-Received: by mail-pa0-f72.google.com with SMTP id rd3sf8853223pab.7 for ; Thu, 19 Jun 2014 09:33:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=AODlboCqld+OkTk3bJ/QE6VhGhPcTlD6tc/EJ46brJY=; b=jWiLpzb2DnAp05fa6cufNhmqJogSgowYzqq8MInmGVYR+OBADvgo/ytu3FuqaxUWia tWRwym+Gsca3D3VYy9wAdVxZimVr6OVm3iSudsJoV8tbPnJmF0b9OmNvkWs7VTmV94+b t/52648p2gMApr//84/p1/slTcJ7rfs2TT63ScGxaUqqxdLw9z8MXi/bGH0GuXZuFQGv h+7CCfG1i+PsaBRxvQUZndleBEFzFBy7fj4pGZ7lawqmmm18vs7JxhkskOW8MtAPPGmK T5zqchyR1RAHyfNXkDPrjhaXfnLuV0kyPaTBVlghX54zp8NtdqM9nugurE5g3iOQuBIK edaQ== X-Gm-Message-State: ALoCoQm4LlM9J9E9DX/RGU9gmCZqUXURZIKhOkXNir2JYuP6n240yXQKP49aSJSPWGI1aOprkGwR X-Received: by 10.66.137.2 with SMTP id qe2mr2638088pab.43.1403195634031; Thu, 19 Jun 2014 09:33:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.100.208 with SMTP id s74ls638850qge.68.gmail; Thu, 19 Jun 2014 09:33:53 -0700 (PDT) X-Received: by 10.140.50.239 with SMTP id s102mr121112qga.7.1403195633182; Thu, 19 Jun 2014 09:33:53 -0700 (PDT) In-Reply-To: <60caa4ef-b32d-40fe-97b6-8918fbb2bd51@isocpp.org> X-Original-Sender: freejazz@tlen.pl 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:11529 Archived-At: ------=_Part_503_20055616.1403195632558 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good point, initialisation of variables is good for "safety" (state is=20 known from the very beginning) but it may cost too much. Initialisation of= =20 variables is done as in C - I think that's by C++ design.=20 Please have a look at the following snippet.=20 explicit struct S {}; typedef explicit int int_type; int_type i; // error: explicit initialisation is required static int_type; // OK - implicitly to 0 int i; // OK S s; // error: explicit initialisation is required static S s; // OK if S has default constructor, we have this already This does not break backward compatibility and reuses "explicit" keyword to= =20 identify types (not type instances, objects) that require explicit=20 initialisation. --=20 Krzysztof W dniu wtorek, 17 czerwca 2014 17:49:57 UTC+2 u=C5=BCytkownik Matthew Fiora= vante=20 napisa=C5=82: > > This is going to be controversial, but lets get into it. > > The fact that `int x;` creates an uninitialized integer instead of a=20 > default initialized one is completely wrong. I consider it a major defect= =20 > in the language, a bug in the standard. > > One of my favorite C++11 API's is the atomic API. The reason is that it= =20 > does the right thing when it comes to correctness vs speed. By default, t= he=20 > path of least resistance is to have everything sequentially consistent=20 > which is the safest but also slowest memory ordering. If you know what=20 > you're doing and need some speed, you can opt to use less safe orderings.= =20 > Even better, every use of the less safe ordering is tagged right there in= =20 > the source code (without a comment)! It really doesn't get much better th= an=20 > that in terms of API design. It follows Scott Meyers maxim of "Making=20 > interfaces easy to use correctly and hard to use incorrectly" perfectly. > > Initialization in C++ is the exact opposite of this. The easiest thing to= =20 > do is write bugs by forgetting to initialize things. How many of you have= =20 > spent long debugging sessions only to track the source to an uninitialize= d=20 > variable? Not only that, but initialization in C++ is a horrible mess. le= ts=20 > look at the list: > > Default initialization > Value Initialization > Copy Initialization > Direct Initialization > Aggregate Initialization > List initialization > Reference Initialization > Constant Initialization > > Do you know by memory how all of those work and their gotchas? I sure as= =20 > hell don't and I pity the novice developer who tries. Do we need this lev= el=20 > of complexity? > > Here is a sketch one possible way we could solve this problem: > > int x; //<-default initialized to 0 > int x =3D void; //<-uninitialized, I know what I'm doing > volatile int x; //<-uninitialized, because we can't introduce=20 > additional writes to volatile variables or break existing device driver= =20 > code. > > Like the atomic API, the default action is the safe action, with options= =20 > to remove the restraints should you need it. > What I'm suggesting is that everything be initialized by default. And yes= =20 > that means all legacy code that flips the switch to use the next version = of=20 > the C++ language. If someone has a compelling performance argument for=20 > leaving something uninitialized, the =3D void syntax is there for them. > > What are the advantages: > 1) Safe by default, if someone does a statistical survey, I'm confident= =20 > that after this change the average amount of time spent debugging C++ cod= e=20 > will go down. > 2) Dangerous places are marked (=3Dvoid) as such, bringing attention and= =20 > carefully scrutiny by the person reading code. > 3) Less boilerplate code. Particularly with constructors I don't have to= =20 > write a bunch of stupid initialization code for my ints, floats, and=20 > pointers. > 4) Initialization behavior matches static and global variables. One less= =20 > "except when" for Herb Sutter to write about in GotW. > > Counter arguments: > 1) This will slow down everyone's programs! > > No it won't. Compilers have been doing something called constant=20 > propagation for over 20 years. > > That is, this code: > > int x =3D 0; > x =3D 1; > > Will be optimized to this: > int x =3D 1; > > 2) This will break C compatibility! > > No it won't. extern "C" code will still have the old behavior. There is n= o=20 > C breakage here. The data being passed to and from C code is still the=20 > same, regardless of whether or not it was initialized by the compiler. > > 3) Why do we need this? Compilers, static checkers, and debugging tools= =20 > can detect uninitialized use! > > Not always, and these tools are not always available. For example valgrin= d=20 > is unusable on large resource consuming code bases. Also, even if there i= s=20 > a tool why am I wasting my time checking this crap? I'd rather not be abl= e=20 > to easily write these bugs in the first place. Fix this and one *major*= =20 > class of bugs in C++ go away forever. > > 4) It will break legacy code! > > In some cases yes, but lets take a deeper look at the possibilities here: > > There are legacy code bases with real uninitialized variable bugs in them= =20 > today. Your company probably has 1 or 2 in their large code base and=20 > miraculously its still working fine. If all of the sudden these things ge= t=20 > fixed, it may change the behavior of your program, causing a "bug" in the= =20 > sense that production is now operating differently. What used to be=20 > undefined behavior just got defined. I don't see this as a huge problem. = If=20 > you have bugs in your code they need to be fixed. Also I do not believe= =20 > this is a good enough reason to continue the subpar status quo forever. > > Then there may be other cases, for example some kind of strange embedded= =20 > code or device drivers. Perhaps you instantiate an object over top of a= =20 > hardware memory address. If you are doing this, you are probably also=20 > marking your variables as volatile, and that as I proposed above is still= =20 > uninitialized so you won't be affected. > > Maybe you're doing something really funky like putting your call stack on= =20 > some special memory, and default initialization will cause additional=20 > writes which will cause your program to fail. If you're doing this kind = of=20 > crazy low level stuff, then you should know enough to be able to fix your= =20 > code. Also you will be now annotating these instances with =3D void or=20 > volatile and that has the additional benefit of saying in your code,=20 > without a comment "*hey I'm doing some funny stuff here with=20 > initialization*". > > 5) I'm so good I don't write these kinds of bugs > > Congratulations, good job. Your colleagues however do write these kind of= =20 > bugs and will continue to do so until the end of time. Sometimes you may= =20 > even get to debug for them. > > I really enjoy C++, for all of its warts. I believe unlike other language= s=20 > which come and go, C++ has staying power and will be around and growing f= or=20 > a long time. C++ is the fastest and most versatile language on the planet= .. =20 > I don't see everyone jumping ship anytime soon for a complete rewrite=20 > language like D (sorry Andrei). We're stuck with C++, so lets make it a= =20 > better language. > > Doing something like this would be huge. It would require a lot of=20 > analysis to get right. My simple idea of =3Dvoid (inspired from D, thanks= =20 > Andrei) may not work in all cases and will need to be fleshed out further= .. > > Please now, convince if you can why this is a bad idea. Why should we=20 > continue to inflict wasted hours of debugging sessions for these kinds of= =20 > silly easy to write bugs on the future of C++? Can you think of any=20 > possible reason uninitialized by default is good other than "maintaining= =20 > legacy code". > > > > --=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/. ------=_Part_503_20055616.1403195632558 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Good point, initialisation of variables is good for "s= afety" (state is known from the very beginning) but it may cost too much. I= nitialisation of variables is done as in C - I think that's by C++ design. =

Please have a look at the following snippet.

explicit struct S {};

typedef explicit int int_type;

int_type i; // error: explicit initialisatio= n is required
sta= tic int_ty= pe;= // OK - implicitly to 0
int i; // OK

S s; // error: explicit initialisation is required
static S s; // OK if S has default constructor, we have this already



This does not break backward compatibility and reuses "expl= icit" keyword to identify types (not type instances, objects) that require = explicit initialisation.

--
Krzysztof


W dniu wtorek, = 17 czerwca 2014 17:49:57 UTC+2 u=C5=BCytkownik Matthew Fioravante napisa=C5= =82:
This is g= oing to be controversial, but lets get into it.

The fact that `int x= ;` creates an uninitialized integer instead of a default initialized one is= completely wrong. I consider it a major defect in the language, a bug in t= he standard.

One of my favorite C++11 API's is the atomic API. The r= eason is that it does the right thing when it comes to correctness vs speed= .. By default, the path of least resistance is to have everything sequential= ly consistent which is the safest but also slowest memory ordering. If you = know what you're doing and need some speed, you can opt to use less safe or= derings. Even better, every use of the less safe ordering is tagged right t= here in the source code (without a comment)! It really doesn't get much bet= ter than that in terms of API design. It follows Scott Meyers maxim of "Mak= ing interfaces easy to use correctly and hard to use incorrectly" perfectly= ..

Initialization in C++ is the exact opposite of this. The easiest t= hing to do is write bugs by forgetting to initialize things. How many of yo= u have spent long debugging sessions only to track the source to an uniniti= alized variable? Not only that, but initialization in C++ is a horrible mes= s. lets look at the list:

Default initialization
Value Initializa= tion
Copy Initialization
Direct Initialization
Aggregate Initializ= ation
List initialization
Reference Initialization
Constant Initia= lization

Do you know by memory how all of those work and their gotch= as? I sure as hell don't and I pity the novice developer who tries. Do we n= eed this level of complexity?

Here is a sketch one possible way we c= ould solve this problem:

    int x; //<-default in= itialized to 0
    int x =3D void; //<-uninitialized, = I know what I'm doing
    volatile int x; //<-uninitia= lized, because we can't introduce additional writes to volatile variables o= r break existing device driver code.

Like the atomic API, the defaul= t action is the safe action, with options to remove the restraints should y= ou need it.
What I'm suggesting is that everything be initialized by def= ault. And yes that means all legacy code that flips the switch to use the n= ext version of the C++ language. If someone has a compelling performance ar= gument for leaving something uninitialized, the =3D void syntax is there fo= r them.

What are the advantages:
1) Safe by default, if someone d= oes a statistical survey, I'm confident that after this change the average = amount of time spent debugging C++ code will go down.
2) Dangerous place= s are marked (=3Dvoid) as such, bringing attention and carefully scrutiny b= y the person reading code.
3) Less boilerplate code. Particularly with c= onstructors I don't have to write a bunch of stupid initialization code for= my ints, floats, and pointers.
4) Initialization behavior matches stati= c and global variables. One less "except when" for Herb Sutter to write abo= ut in GotW.

Counter arguments:
1) This will slow down everyone's = programs!

No it won't. Compilers have been doing something called co= nstant propagation for over 20 years.

That is, this code:

&nb= sp;   int x =3D 0;
    x =3D 1;

Will be = optimized to this:
    int x =3D 1;

2) This will b= reak C compatibility!

No it won't. extern "C" code will still have t= he old behavior. There is no C breakage here. The data being passed to and = from C code is still the same, regardless of whether or not it was initiali= zed by the compiler.

3) Why do we need this? Compilers, static check= ers, and debugging tools can detect uninitialized use!

Not always, a= nd these tools are not always available. For example valgrind is unusable o= n large resource consuming code bases. Also, even if there is a tool why am= I wasting my time checking this crap? I'd rather not be able to easily wri= te these bugs in the first place. Fix this and one major class of bu= gs in C++ go away forever.

4) It will break legacy code!

In s= ome cases yes, but lets take a deeper look at the possibilities here:
There are legacy code bases with real uninitialized variable bugs in them= today. Your company probably has 1 or 2 in their large code base and mirac= ulously its still working fine. If all of the sudden these things get fixed= , it may change the behavior of your program, causing a "bug" in the sense = that production is now operating differently. What used to be undefined beh= avior just got defined. I don't see this as a huge problem. If you have bug= s in your code they need to be fixed. Also I do not believe this is a good = enough reason to continue the subpar status quo forever.

Then there = may be other cases, for example some kind of strange embedded code or devic= e drivers. Perhaps you instantiate an object over top of a hardware memory = address. If you are doing this, you are probably also marking your variable= s as volatile, and that as I proposed above is still uninitialized so you w= on't be affected.

Maybe you're doing something really funky like put= ting your call stack on some special memory, and default initialization wil= l cause additional writes which will cause your program to fail.  If y= ou're doing this kind of crazy low level stuff, then you should know enough= to be able to fix your code. Also you will be now annotating these instanc= es with =3D void or volatile and that has the additional benefit of saying = in your code, without a comment "hey I'm doing some funny stuff here wit= h initialization".

5) I'm so good I don't write these kinds of b= ugs

Congratulations, good job. Your colleagues however do write thes= e kind of bugs and will continue to do so until the end of time. Sometimes = you may even get to debug for them.

I really enjoy C++, for all of i= ts warts. I believe unlike other languages which come and go, C++ has stayi= ng power and will be around and growing for a long time. C++ is the fastest= and most versatile language on the planet.  I don't see everyone jump= ing ship anytime soon for a complete rewrite language like D (sorry Andrei)= .. We're stuck with C++, so lets make it a better language.

Doing som= ething like this would be huge. It would require a lot of analysis to get r= ight. My simple idea of =3Dvoid (inspired from D, thanks Andrei) may not wo= rk in all cases and will need to be fleshed out further.

Please now,= convince if you can why this is a bad idea. Why should we continue to infl= ict wasted hours of debugging sessions for these kinds of silly easy to wri= te bugs on the future of C++? Can you think of any possible reason uninitia= lized by default is good other than "maintaining legacy code".


<= br>

--

---
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>.
------=_Part_503_20055616.1403195632558-- .