auto init & what the code means

[Jonathan M Davis]

On Monday 27 December 2010 04:28:29 spir wrote:
> On Sun, 26 Dec 2010 14:04:28 -0800
> 
> Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > On Sunday 26 December 2010 07:08:22 Andrei Alexandrescu wrote:
> > > On 12/26/10 8:54 AM, spir wrote:
> > > > On Sun, 26 Dec 2010 14:54:12 +0100
> > > > 
> > > > Andrej Mitrovic<andrej.mitrovich at gmail.com>  wrote:
> > > >> int i;    // auto-initialized to int.init
> > > >> int i = void; // not initialized
> > > > 
> > > > Thanks. Actually this solves my "semantic" issue, did not even think
> > > > at 'void'. (I will use it often). By the way, I don't want to play
> > > > the superhero with uninitialised values, simply sometimes the
> > > > initial value cannot be known at declare place.
> > > > 
> > > > 	int i;
> > > > 	if (foo)
> > > > 	
> > > > 	   i=0;
> > > > 	
> > > > 	else if (bar)
> > > > 	
> > > > 	   i=1;
> > > > 	
> > > > 	else
> > > > 	
> > > > 	   i=2;
> > > > 	
> > > > 	playWith(i);
> > > 
> > > Problem with = void for elaborate types is that you need to use
> > > emplace(&var, expr) to initialize them later.
> > 
> > And of course the _big_  problem with = void is that you're dealing with
> > garbage if you don't actually initialize the variable before you use it.
> > It's a good addition for performance-critical code, but in general, it's
> > a _bad_ idea to use. It solves a major problem which exists in C and C++
> > with regards to undefined and undeterministic behavior. I'd get very
> > worried if I started seeing code that used it all over the place. There
> > are straightforward cases where it's obvious that it's of benefit and
> > obvious that the variable in question is being initialized, but beyond
> > that, it really shouldn't be used.
> > 
> > - Jonathan M Davis
> 
> Right, regarding Andrei's note about void and yours, I think it's better to
> use a plain, but *conventional*, comment. I guess int i=0;
> versus
> 	int i;		// undef
> do the job. The point here (of my initial post) is correct documentation of
> code meaning for the reader's benefit; not changing actual process under
> the hood. But such practices need adoption by a large (or leading)
> proportion of the language's community. Which may be hard because code
> clarity has never been, AFAIK, a primary concern in C-line language uses.

Oh, I think that it's better coding style to use int i = 0; when you want to be 
0 rather than just using int i; It's also better coding style to initialize a 
variable when you declare it if you can. However, there are plenty of cases 
where you can't, and by default initializing all types, you avoid the problems 
that you get in C and C++ where a variable's value is undeterministic garbage 
and yet gets used. It's far better for a variable to be default initialized. 
That way, it's completely deterministic.

Every type is default initialized to the closest thing that it has to an error 
value. In the case of int, that's 0, which isn't really much of an error value, 
but integral values don't have values such as NAN or null, so that's the best 
that the compiler can do. int i; is completely defined, as it should be. There 
will be far fewer bugs that way.

Now, I do think that it's better coding style to use int i = 0; rather than just 
int i; but since the language defines int i; to be identical to int i = 0; it can 
be relied upon, and some people will rely upon it. But while I disagree with 
those who do that, that's still far better than having int i; be undefined.

- Jonathan M Davis