220 11482 <91f8064b-a08a-4a23-98f4-f3ccde0a2213@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Controversy and debate: Uninitialized variables by default is a bug Date: Tue, 17 Jun 2014 09:00:47 -0700 (PDT) Lines: 393 Approved: news@gmane.org Message-ID: <91f8064b-a08a-4a23-98f4-f3ccde0a2213@isocpp.org> 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_273_10551587.1403020847511" X-Trace: ger.gmane.org 1403020856 8785 80.91.229.3 (17 Jun 2014 16:00:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Jun 2014 16:00:56 +0000 (UTC) Cc: jbcoe@me.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBMGMQGOQKGQEI52INCI@isocpp.org Tue Jun 17 18:00:50 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WwvoX-0003If-Ql for gclcip-std-proposals@m.gmane.org; Tue, 17 Jun 2014 18:00:50 +0200 Original-Received: by mail-vc0-f198.google.com with SMTP id hy10sf25680459vcb.1 for ; Tue, 17 Jun 2014 09:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=Y/ClRBfk7GV83Q7HOjLz9vA+HlJg4jGNoUbc3YfHvoQ=; b=lBtmimf+Dus4vmSE7bwGmgTzYlWLoOKh628RA+zB3scu0Hj+kirdjSLTyPdaQjf6y3 OCeMHZbqdrXmqxk65HHgaaFhyqI6GoZe67JHh04pmtysk0/EVaL5t/3zUi+BUTkEw8Is vqZmUwKoQuf1x4x6UScXcj/LLdzchqJw/v8y+YO1/7e9oP3SyTAR2vt5Gz0zHI3ABqNU 8p/sbFh7HDHVeb2j29O8UX9JW00W4KAinGgJzP53XdXSYI/FUt7b/d+HPXZfVeoZNVTH O4ieI+/0KM/4mR6whUHB/JnABuLA/++vNJl825yLdsop1NkgIFmaqs6LggDXfLnUOVRi x2sw== 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:cc: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=Y/ClRBfk7GV83Q7HOjLz9vA+HlJg4jGNoUbc3YfHvoQ=; b=IHPRHrR+joFzi/9IWn71+Jh6fDShoR5dqz0dd6AXv1QmTuqGmUn7/WZM6ZLMSw8Nxp MboZQa6XDasvbBe+ZxbQ5Oxg4g51VZ/VfgUS0O+tdNZn41w3oVOtw8CfKT+jr6v9JDg2 DHDw+4FF5WZkZq52ouFKTrS29mGXbb7oMES3iHlmtyyJJBM2vDDc32yUXjPEIj9reilI zFEQywhEfkV2QMSa/HbS1taOeHuxNxLAjmKAL+LBUHZXbCMgKp8Aiv8bE0kACPUNdvo4 xSyteTjQsEdHaDXq3PzQiSmXnwPutYR9N770mS4f6YA8As2xizd5EZzPRgfb9jHP1teF +RKw== X-Gm-Message-State: ALoCoQlS2+dPrHzbZm94kxkJ+GB1WTYa9oDN9fZjOb2EyuK86acM5D4RLskeZSgOEmQQUXzQSlyl X-Received: by 10.58.160.72 with SMTP id xi8mr1660831veb.15.1403020848999; Tue, 17 Jun 2014 09:00:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.96.6 with SMTP id j6ls976413qge.89.gmail; Tue, 17 Jun 2014 09:00:48 -0700 (PDT) X-Received: by 10.140.49.67 with SMTP id p61mr58789qga.21.1403020848095; Tue, 17 Jun 2014 09:00:48 -0700 (PDT) In-Reply-To: X-Original-Sender: fmatthew5876@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:11482 Archived-At: ------=_Part_273_10551587.1403020847511 Content-Type: text/plain; charset=UTF-8 On Tuesday, June 17, 2014 11:53:35 AM UTC-4, Jonathan Coe wrote: > > Sometimes (in embedded systems for instance) initialization cost is > considered to be significant. C++ generally follows the philosophy that you > only pay for what you need. User- or library-defined types can force > primitives to be initialized or value initialize them. > The key word here is "sometimes". Sometimes initialization is expensive, most of the time it is not or just optimized away. For those some times, you can use =void, or boost value_init (we could have a std::noinit wrapper), or some other specialized method. As long as this method exists, the only pay for what you need philosophy still sticks. If you find initialization to be expensive, use the alternative method (which also documents your intent in the code without comments). Most of the time when people talk about initialization costs, they are doing something like constructing a vector of objects. This initialization cost is already in the standard because vector will initialize the objects. Nothing I am proposing here changes that or makes it worse. > for instance: > http://www.boost.org/doc/libs/1_55_0/libs/utility/value_init.htm > > Regards, > > Jon > > > On 17 June 2014 17:49, Matthew Fioravante > wrote: > >> This is going 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 the standard. >> >> One of my favorite C++11 API's is the atomic API. The reason 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 sequentially 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 orderings. >> Even better, every use of the less safe ordering is tagged right there in >> the source code (without a comment)! It really doesn't get much better than >> that in terms of API design. It follows Scott Meyers maxim of "Making >> interfaces easy to use correctly and hard to use incorrectly" perfectly. >> >> Initialization in C++ is the exact opposite of this. The easiest thing to >> do is write bugs by forgetting to initialize things. How many of you have >> spent long debugging sessions only to track the source to an uninitialized >> variable? Not only that, but initialization in C++ is a horrible mess. lets >> 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 >> hell don't and I pity the novice developer who tries. Do we need this level >> of complexity? >> >> Here is a sketch one possible way we could solve this problem: >> >> int x; //<-default initialized to 0 >> int x = void; //<-uninitialized, I know what I'm doing >> volatile int x; //<-uninitialized, because we can't introduce >> additional writes to volatile variables or break existing device driver >> code. >> >> Like the atomic API, the default action is the safe action, with options >> to remove the restraints should you need it. >> What I'm suggesting is that everything be initialized by default. And yes >> that means all legacy code that flips the switch to use the next version of >> the C++ language. If someone has a compelling performance argument for >> leaving something uninitialized, the = void syntax is there for them. >> >> What are the advantages: >> 1) Safe by default, if someone does a statistical survey, I'm confident >> that after this change the average amount of time spent debugging C++ code >> will go down. >> 2) Dangerous places are marked (=void) as such, bringing attention and >> carefully scrutiny by the person reading code. >> 3) Less boilerplate code. Particularly with constructors I don't have to >> write a bunch of stupid initialization code for my ints, floats, and >> pointers. >> 4) Initialization behavior matches static and global variables. One less >> "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 >> propagation for over 20 years. >> >> That is, this code: >> >> int x = 0; >> x = 1; >> >> Will be optimized to this: >> int x = 1; >> >> 2) This will break C compatibility! >> >> No it won't. extern "C" code will still have the 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 initialized by the compiler. >> >> 3) Why do we need this? Compilers, static checkers, and debugging tools >> can detect uninitialized use! >> >> Not always, and these tools are not always available. For example >> valgrind is unusable on 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 write these bugs in the first place. Fix this and one >> *major* 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 >> today. Your company probably has 1 or 2 in their large code base and >> miraculously 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 behavior just got defined. I don't see this as a huge problem. If >> you have bugs 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 device drivers. Perhaps you instantiate an object over top of a >> hardware memory address. If you are doing this, you are probably also >> marking your variables as volatile, and that as I proposed above is still >> uninitialized so you won't be affected. >> >> Maybe you're doing something really funky like putting your call stack on >> some special memory, and default initialization will cause additional >> writes which will cause your program to fail. If you'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 instances with = 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 with >> 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 >> 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 its warts. I believe unlike other >> languages which come and go, C++ has staying 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 jumping 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 something like this would be huge. It would require a lot of >> analysis to get right. My simple idea of =void (inspired from D, thanks >> 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 >> continue to inflict wasted hours of debugging sessions for these kinds of >> silly easy to write bugs on the future of C++? Can you think of any >> possible reason uninitialized by default is good other than "maintaining >> legacy code". >> >> >> >> -- >> >> --- >> 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-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> Visit this group at >> http://groups.google.com/a/isocpp.org/group/std-proposals/. >> > > -- --- 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/. ------=_Part_273_10551587.1403020847511 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, June 17, 2014 11:53:35 AM UTC-4, Jonat= han Coe wrote:
Sometimes (in embedded systems for instance) initialization cost is consid= ered to be significant. C++ generally follows the philosophy that you only = pay for what you need. User- or library-defined types can force primitives = to be initialized or value initialize them.

The = key word here is "sometimes". Sometimes initialization is expensive, most o= f the time it is not or just optimized away. For those some times, you can = use =3Dvoid, or boost value_init (we could have a std::noinit<T> wrap= per), or some other specialized method. As long as this method exists, the = only pay for what you need philosophy still sticks. If you find initializat= ion to be expensive, use the alternative method (which also documents your = intent in the code without comments).

Most of the time when people t= alk about initialization costs, they are doing something like constructing = a vector of objects. This initialization cost is already in the standard be= cause vector will initialize the objects. Nothing I am proposing here chang= es that or makes it worse.





On 17 Jun= e 2014 17:49, Matthew Fioravante <fmatth...@gmail.com> wrote:
This is going to be controv= ersial, but lets get into it.

The fact that `int x;` creates an unin= itialized integer instead of a default initialized one is completely wrong.= I consider it a major defect 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= does the right thing when it comes to correctness vs speed. By default, th= e path of least resistance is to have everything sequentially consistent wh= ich 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 orderings. Even be= tter, every use of the less safe ordering is tagged right there in the sour= ce code (without a comment)! It really doesn't get much better than that in= terms of API design. It follows Scott Meyers maxim of "Making interfaces e= asy to use correctly and hard to use incorrectly" perfectly.

Initialization in C++ is the exact opposite of this. The easiest thing = to do is write bugs by forgetting to initialize things. How many of you hav= e spent long debugging sessions only to track the source to an uninitialize= d variable? Not only that, but initialization in C++ is a horrible mess. le= ts look at the list:

Default initialization
Value Initialization
Copy InitializationDirect Initialization
Aggregate Initialization
List initialization<= br>Reference Initialization
Constant Initialization

Do you know b= y memory how all of those work and their gotchas? I sure as hell don't and = I pity the novice developer who tries. Do we need this level of complexity?=

Here is a sketch one possible way we could solve this problem:

&= nbsp;   int x; //<-default initialized to 0
  &nb= sp; int x =3D void; //<-uninitialized, I know what I'm doing
 &n= bsp;  volatile int x; //<-uninitialized, because we can't introduce= additional writes to volatile variables or break existing device driver co= de.

Like the atomic API, the default action is the safe action, with option= s to remove the restraints should you need it.
What I'm suggesting is th= at everything be initialized by default. And yes that means all legacy code= that flips the switch to use the next version of the C++ language. If some= one has a compelling performance argument for leaving something uninitializ= ed, the =3D void syntax is there for them.

What are the advantages:
1) Safe by default, if someone does a stati= stical survey, I'm confident that after this change the average amount of t= ime spent debugging C++ code will go down.
2) Dangerous places are marke= d (=3Dvoid) as such, bringing attention and carefully scrutiny by the perso= n reading code.
3) Less boilerplate code. Particularly with constructors I don't have to wr= ite a bunch of stupid initialization code for my ints, floats, and pointers= ..
4) Initialization behavior matches static and global variables. One le= ss "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 propagat= ion for over 20 years.

That is, this code:

   = int x =3D 0;
    x =3D 1;

Will be optimized to this:
 &nbs= p;  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 no C b= reakage here. The data being passed to and from C code is still the same, r= egardless of whether or not it was initialized by the compiler.

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

Not always, and these tools are not a= lways available. For example valgrind is unusable on large resource consumi= ng code bases. Also, even if there is a tool why am I wasting my time check= ing this crap? I'd rather not be able to easily write these bugs in the fir= st place. Fix this and one major class of bugs in C++ go away foreve= r.

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 today. Your company probably = has 1 or 2 in their large code base and miraculously its still working fine= .. If all of the sudden these things get fixed, it may change the behavior o= f your program, causing a "bug" in the sense that production is now operati= ng differently. What used to be undefined behavior just got defined. I don'= t see this as a huge problem. If you have bugs 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 embedde= d code or device drivers. Perhaps you instantiate an object over top of a h= ardware memory address. If you are doing this, you are probably also markin= g your variables as volatile, and that as I proposed above is still uniniti= alized so you won't be affected.

Maybe you're doing something really funky like putting your call stack = on some special memory, and default initialization will cause additional wr= ites which will cause your program to fail.  If you're doing this kind= of crazy low level stuff, then you should know enough to be able to fix yo= ur code. Also you will be now annotating these instances with =3D void or v= olatile and that has the additional benefit of saying in your code, without= a comment "hey I'm doing some funny stuff here with 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 bugs and will co= ntinue to do so until the end of time. Sometimes you may even get to debug = for them.

I really enjoy C++, for all of its warts. I believe unlike other langua= ges which come and go, C++ has staying power and will be around and growing= for a long time. C++ is the fastest and most versatile language on the pla= net.  I don't see everyone jumping ship anytime soon for a complete re= write language like D (sorry Andrei). We're stuck with C++, so lets make it= a better language.

Doing something like this would be huge. It would require a lot of anal= ysis to get right. My simple idea of =3Dvoid (inspired from D, thanks Andre= i) 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 c= ontinue to inflict wasted hours of debugging sessions for these kinds of si= lly easy to write bugs on the future of C++? Can you think of any possible = reason uninitialized by default is good other than "maintaining legacy code= ".



--

---
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-proposal...@isocpp.or= g.
To post to this group, send email to s= td-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposal= s/.

--

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