"James Kanze" <james.kanze@gmail.com> wrote in message
news:5676c3d5-813c-454f-8b2d-

>> void foo() {
>>     struct { unsigned size; int array[10000]; } x;
>>     x.size = 0;
>>     // ...
>
>> }

> If that's the entire code, the compiler can recognize that
> x.array is never used, and suppress it completely.  If it is
> used in what replaces the //..., then whether the compiler can
> suppress all or part of the initialization or not depends on how
> it is used, and how smart the compiler is.

Of course it can.  But this example is intended to suggest a common
usage in
which x.size keeps track of how many elements of x.array are in use at the
moment.  In general, it is not possible for a compiler to be smart
enough to
discover this usage, which means that it is not possible for a compiler to
avoid initializing elements of x.array needlessly.

An example much like this one was the one that killed the proposal to
zero-initialize all POD variables the first time the argument came before
the committee, on the basis that it would put C++ at a performance
disadvantage compared to C.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

What argument can there be, against implicit zero initialisation of all
POD types in all situations, being
adopted in the C++ standard, when there is no explicit initialisation
provided by the programmer?



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

I Like the idea.  But then again I'm just starting to program; so, any
default initialization is a blessing to me.  This one will have
problems from others more experienced than me though.  Just wait and
see what they say.




On Thu,  9 Apr 2009 11:42:32 CST, Ioannis Vranos <ivranos@freemail.gr>
wrote:

>What argument can there be, against implicit zero initialisation of all
>POD types in all situations, being
>adopted in the C++ standard, when there is no explicit initialisation
>provided by the programmer?

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Ioannis Vranos" <ivranos@freemail.gr>
> What argument can there be, against implicit zero initialisation of all
> POD types in all situations, being
> adopted in the C++ standard, when there is no explicit initialisation
> provided by the programmer?

Performance. Nuff said.

Btw, IMNSHO you could have more success here if you read some books like
Bjarne's 'Design and Evolution of C++' or the WG21 papers: what is on the
table, what got accepted or rejected.



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

jackOrip wrote:
> I Like the idea.  But then again I'm just starting to program; so, any
> default initialization is a blessing to me.  This one will have
> problems from others more experienced than me though.  Just wait and
> see what they say.
>
>
>
>
> On Thu,  9 Apr 2009 11:42:32 CST, Ioannis Vranos <ivranos@freemail.gr>
> wrote:
>
>> What argument can there be, against implicit zero initialisation of all
>> POD types in all situations, being
>> adopted in the C++ standard, when there is no explicit initialisation
>> provided by the programmer?


Having rethought the idea, I think the best thing would be, getting
implementation diagnostics for any
unitialised POD object, rather than initialising it with 0 implicitly.





--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 10, 6:38 am, "Balog Pal" <p...@lib.hu> wrote:
> "Ioannis Vranos" <ivra...@freemail.gr>

> > What argument can there be, against implicit zero
> > initialisation of all POD types in all situations, being
> > adopted in the C++ standard, when there is no explicit
> > initialisation provided by the programmer?

> Performance. Nuff said.

Except that there are very, very few cases where it would make
any difference.  The most obvious one is something like:
     int i ;
     std::cin >> i ;
.  But in such cases, the cost of initializing i with 0 is
negligeable compared to the cost of the >> operator.)

The most fundamental reason why it wasn't adapted is that it
wasn't in C, and since then, no one has made an actual proposal
which could be discussed.  (And it's too late for anything new
in C++0x.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
>
> On Apr 10, 6:38 am, "Balog Pal" <p...@lib.hu> wrote:
>>
>> "Ioannis Vranos" <ivra...@freemail.gr>
>
>>> What argument can there be, against implicit zero
>>> initialisation of all POD types in all situations, being
>>> adopted in the C++ standard, when there is no explicit
>>> initialisation provided by the programmer?
>
>> Performance. Nuff said.
>
> Except that there are very, very few cases where it would make
> any difference.

Definition of large automatic arrays is one case where I've seen
significant performance costs from zero-initialization. I know that
some people use systems where it's not possible to define such arrays,
but it is both feasible and commonplace in the code I work on.
Removing all unneeded zero-initialization caused something like a 10%
increase in the speed of one of my programs.

I've also seen explicit zero-initialization of a large automatic array
cause an enormous increase in the size of the executed. However, that
was due to what I consider an idiotic compiler: it translated

double array[40][204][5416]={0.0};

into code equivalent to the following:

double array[40][204][5416];
array[0][0][0] = 0.0;
array[0][0][1] = 0.0;
/* ... */
array[39][203][5415] = 0.0;

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com>
>
>> > What argument can there be, against implicit zero
>> > initialisation of all POD types in all situations, being
>> > adopted in the C++ standard, when there is no explicit
>> > initialisation provided by the programmer?
>
>> Performance. Nuff said.
>
> Except that there are very, very few cases where it would make
> any difference.

Maybe/probably so, but from the standard's POW there is no way to measure.
And even a few cases is too many.  As access to not inited thing is UB, any
implemetation is free to do zero-init on its own, backed up with
documentation, compiler switch, etc.  So there is no problem to solve it the
QoI way.

But making zero-init mandatory goes against the 'you don't pay' design
principle. To eliminate the price systems must have good optimizers...

>The most obvious one is something like:
>     int i ;
>     std::cin >> i ;
> .  But in such cases, the cost of initializing i with 0 is
> negligeable compared to the cost of the >> operator.)

How about

char buf[1000000];
buf[0] = 0;

The code semantics may want just use the buf for 0-term strings, so the
array is inited. But the compiler now must fill it all, and hardly have a
way to know enough to skip it.
I guess we have a zillion lines of such code sitting around.

> The most fundamental reason why it wasn't adapted is that it
> wasn't in C, and since then, no one has made an actual proposal
> which could be discussed.  (And it's too late for anything new
> in C++0x.)

I recall discussion of this at least a dozen times here and other groups.
IIRC we all agreed that it would be something nice to have (even as
extension) but even that much is unlikely to happen.

The form I liked most looked like:

int i; // gets 0-init
int j = _Noinit;  // works like  old  int j

so it is expressive to write and read, can be grep-ed, etc.



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Balog Pal wrote:
>
> I recall discussion of this at least a dozen times here and other groups.
> IIRC we all agreed that it would be something nice to have (even as
> extension) but even that much is unlikely to happen.
>
> The form I liked most looked like:
>
> int i; // gets 0-init
> int j = _Noinit;  // works like  old  int j
>
> so it is expressive to write and read, can be grep-ed, etc.


What do you think of being required to produce just warning messages for
any unitialised POD type?


--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Ioannis Vranos wrote:
> Balog Pal wrote:
>>
>> I recall discussion of this at least a dozen times here and other groups.
>> IIRC we all agreed that it would be something nice to have (even as
>> extension) but even that much is unlikely to happen.
>>
>> The form I liked most looked like:
>>
>> int i; // gets 0-init
>> int j = _Noinit;  // works like  old  int j
>>
>> so it is expressive to write and read, can be grep-ed, etc.
>
>
> What do you think of being required to produce just warning messages for
> any unitialised POD type?
>
>

The Standard has no concept of a warning message. All Standards have is
the concept of a diagnostic.  So my answer is that a warning would be a
fine thing for a quality compiler to do but it is not possible to
specify that an implementation must produce specifically a warning as
opposed to an error. All we can do is require a diagnostic.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Balog Pal wrote:
> "James Kanze" <james.kanze@gmail.com>
>>>> What argument can there be, against implicit zero
>>>> initialisation of all POD types in all situations, being
>>>> adopted in the C++ standard, when there is no explicit
>>>> initialisation provided by the programmer?
>>> Performance. Nuff said.
>> Except that there are very, very few cases where it would make
>> any difference.
>
> Maybe/probably so, but from the standard's POW there is no way to measure.
> And even a few cases is too many.  As access to not inited thing is UB, any
> implemetation is free to do zero-init on its own, backed up with
> documentation, compiler switch, etc.  So there is no problem to solve it the
> QoI way.
>
> But making zero-init mandatory goes against the 'you don't pay' design
> principle. To eliminate the price systems must have good optimizers...
>
>> The most obvious one is something like:
>>     int i ;
>>     std::cin >> i ;
>> .  But in such cases, the cost of initializing i with 0 is
>> negligeable compared to the cost of the >> operator.)
>
> How about
>
> char buf[1000000];
> buf[0] = 0;
>
> The code semantics may want just use the buf for 0-term strings, so the
> array is inited. But the compiler now must fill it all, and hardly have a
> way to know enough to skip it.
> I guess we have a zillion lines of such code sitting around.
>
>> The most fundamental reason why it wasn't adapted is that it
>> wasn't in C, and since then, no one has made an actual proposal
>> which could be discussed.  (And it's too late for anything new
>> in C++0x.)


The main issue is with large arrays where initialisation can be
expensive. And it can be very expensive if the array size exceeds
available fast memory because it forces the program to touch every
element of the array even if the program otherwise only actually touches
a small number of elements.

There is also the case of the debugging implementation that can
currently initialise objects with a special value that identifies that
it has not been initialised. Once you have default initialisation this
becomes much harder as the debugging version must behave differently to
(and in a non-standard way) to a non-debugging version.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

on Fri Apr 10 2009, James Kanze <james.kanze-AT-gmail.com> wrote:

> On Apr 10, 6:38 am, "Balog Pal" <p...@lib.hu> wrote:
>> "Ioannis Vranos" <ivra...@freemail.gr>
>
>> > What argument can there be, against implicit zero
>> > initialisation of all POD types in all situations, being
>> > adopted in the C++ standard, when there is no explicit
>> > initialisation provided by the programmer?
>
>> Performance. Nuff said.
>
> Except that there are very, very few cases where it would make
> any difference.  The most obvious one is something like:
>      int i ;
>      std::cin >> i ;
> .  But in such cases, the cost of initializing i with 0 is
> negligeable compared to the cost of the >> operator.)

The obvious case is:

   aut_ptr<char> receive_buffer( allocate(huge_number_of_elements) );
   mpi_receive(receive_buffer.get(), huge_number_of_elements);

> The most fundamental reason why it wasn't adapted is that it
> wasn't in C, and since then, no one has made an actual proposal
> which could be discussed.  (And it's too late for anything new
> in C++0x.)

No, it does get discussed in committee, and when it does, the issue
comes back to performance.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
>
> The Standard has no concept of a warning message. All Standards have is
> the concept of a diagnostic.  So my answer is that a warning would be a
> fine thing for a quality compiler to do but it is not possible to
> specify that an implementation must produce specifically a warning as
> opposed to an error. All we can do is require a diagnostic.


OK then, having the standard requiring only a diagnostic for every
unitialised POD object. I think that would lead to more reliable code,
without breaking existing code.



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 5:57 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> Ioannis Vranos wrote:
> > Balog Pal wrote:

> >> I recall discussion of this at least a dozen times here and
> >> other groups.  IIRC we all agreed that it would be
> >> something nice to have (even as extension) but even that
> >> much is unlikely to happen.

> >> The form I liked most looked like:

> >> int i; // gets 0-init
> >> int j = _Noinit;  // works like  old  int j

> >> so it is expressive to write and read, can be grep-ed, etc.

> > What do you think of being required to produce just warning
> > messages for any unitialised POD type?

> The Standard has no concept of a warning message. All
> Standards have is the concept of a diagnostic.  So my answer
> is that a warning would be a fine thing for a quality compiler
> to do but it is not possible to specify that an implementation
> must produce specifically a warning as opposed to an error.
> All we can do is require a diagnostic.

But an implementation is allowed to treat a warning as a
diagnostic.  So formally, a compiler could just issue warnings
for uninitialized variables, if that's what it's user community
wanted (or if the vendor thought that would sell more
compilers).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 8:57 am, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> >> I recall discussion of this at least a dozen times here and other groups.
> >> IIRC we all agreed that it would be something nice to have (even as
> >> extension) but even that much is unlikely to happen.
>
> >> The form I liked most looked like:
>
> >> int i; // gets 0-init
> >> int j = _Noinit;  // works like  old  int j
>
> >> so it is expressive to write and read, can be grep-ed, etc.
>
> > What do you think of being required to produce just warning messages for
> > any unitialised POD type?
>
> The Standard has no concept of a warning message. All Standards have is
> the concept of a diagnostic.  So my answer is that a warning would be a
> fine thing for a quality compiler to do but it is not possible to
> specify that an implementation must produce specifically a warning as
> opposed to an error. All we can do is require a diagnostic.

True, but the mere presence of the ability to explicitly state "this
is uninitialized" would likely lead most compilers to issue a warning
there by default.

In general, I would also prefer everything to be either explicitly
initialized, or explicitly marked as uninitialized, with anything else
being suspect.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 11, 10:41 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> James Kanze wrote:

> > On Apr 10, 6:38 am, "Balog Pal" <p...@lib.hu> wrote:

> >> "Ioannis Vranos" <ivra...@freemail.gr>

> >>> What argument can there be, against implicit zero
> >>> initialisation of all POD types in all situations, being
> >>> adopted in the C++ standard, when there is no explicit
> >>> initialisation provided by the programmer?

> >> Performance. Nuff said.

> > Except that there are very, very few cases where it would make
> > any difference.

> Definition of large automatic arrays is one case where I've
> seen significant performance costs from zero-initialization. I
> know that some people use systems where it's not possible to
> define such arrays, but it is both feasible and commonplace in
> the code I work on.  Removing all unneeded zero-initialization
> caused something like a 10% increase in the speed of one of my
> programs.

That's the traditional case.  But given current compiler
technology, I would imagine that in most cases, if the array
were really initialized before use, the compiler would be able
to detect it.  And of course, the compiler can forego zero
initialization anytime it detects that some other value is
written before the 0 is read.

In other words, given something like:

     void
     f()
     {
         int array[ 1000 ][ 1000 ] ;
         for ( int i = 0 ; i < 1000 ; ++ i ) {
             for ( int j = 0 ; j < 1000 ; ++ j ) {
                 array[ i ]] j ] = 1000 * i + j ;
             }
         }
         // ...
     }

I would expect absolutely no change in the generated code if 0
initialization were requested.

> I've also seen explicit zero-initialization of a large
> automatic array cause an enormous increase in the size of the
> executed. However, that was due to what I consider an idiotic
> compiler: it translated

> double array[40][204][5416]={0.0};

> into code equivalent to the following:

> double array[40][204][5416];
> array[0][0][0] = 0.0;
> array[0][0][1] = 0.0;
> /* ... */
> array[39][203][5415] = 0.0;

Ouch.  But even without 0 initialization, a compiler is always
free to make a mess of things.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 5:56 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> Balog Pal wrote:
> > "James Kanze" <james.ka...@gmail.com>
> >>>> What argument can there be, against implicit zero
> >>>> initialisation of all POD types in all situations, being
> >>>> adopted in the C++ standard, when there is no explicit
> >>>> initialisation provided by the programmer?
> >>> Performance. Nuff said.
> >> Except that there are very, very few cases where it would make
> >> any difference.

> > Maybe/probably so, but from the standard's POW there is no
> > way to measure.  And even a few cases is too many.  As
> > access to not inited thing is UB, any implemetation is free
> > to do zero-init on its own, backed up with documentation,
> > compiler switch, etc.  So there is no problem to solve it
> > the QoI way.
>
> > But making zero-init mandatory goes against the 'you don't
> > pay' design principle. To eliminate the price systems must
> > have good optimizers...

> >> The most obvious one is something like:
> >>     int i ;
> >>     std::cin >> i ;
> >> .  But in such cases, the cost of initializing i with 0 is
> >> negligeable compared to the cost of the >> operator.)

> > How about

> > char buf[1000000];
> > buf[0] = 0;

> > The code semantics may want just use the buf for 0-term
> > strings, so the array is inited. But the compiler now must
> > fill it all, and hardly have a way to know enough to skip
> > it.  I guess we have a zillion lines of such code sitting
> > around.

You might have a point there.  Theoretically, at least, the
compiler could know enough about zero terminated strings to
avoid the initialization (which really only has to occur if the
element is read before it is first written), but it is pushing
compiler technology (unlike my example in response to James
Kuyper).  Especially if the initialization occurs in another
translation unit.

> >> The most fundamental reason why it wasn't adapted is that
> >> it wasn't in C, and since then, no one has made an actual
> >> proposal which could be discussed.  (And it's too late for
> >> anything new in C++0x.)

> The main issue is with large arrays where initialisation can
> be expensive. And it can be very expensive if the array size
> exceeds available fast memory because it forces the program to
> touch every element of the array even if the program otherwise
> only actually touches a small number of elements.

Only if the compiler can't prove that the memory isn't read
before it is written with another value.

> There is also the case of the debugging implementation that
> can currently initialise objects with a special value that
> identifies that it has not been initialised. Once you have
> default initialisation this becomes much harder as the
> debugging version must behave differently to (and in a
> non-standard way) to a non-debugging version.

That's really the major argument against it that I see.  Many
modern development systems (e.g. Purify) can detect reads of
uninitialized data already, and that's probably even more useful
than 0 initialization.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com> wrote:
> On Apr 11, 10:41 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> Definition of large automatic arrays is one case where I've
>> seen significant performance costs from zero-initialization. I
>> know that some people use systems where it's not possible to
>> define such arrays, but it is both feasible and commonplace in
>> the code I work on.  Removing all unneeded zero-initialization
>> caused something like a 10% increase in the speed of one of my
>> programs.
>
> That's the traditional case.  But given current compiler
> technology, I would imagine that in most cases, if the array
> were really initialized before use, the compiler would be able
> to detect it.  And of course, the compiler can forego zero
> initialization anytime it detects that some other value is
> written before the 0 is read.
>

Perhaps, but quite possibly only when compiled with optimization. And
compiling with optimization is not always possible. Now a small number of
optimizations get applied even when optimizations are off in most
compilers,
but generally only those that could not be seen when stepping through the
code in a debugger, and which don't require information only generated when
optimizing. The sort of information this optimization would need would only
be generated when optimizing.

Therefore with gcc at least, every single program (when compiled without
optimization) that declares variables that are not immediately initialized
would run slower (than it currently does) if such a requirement were
present
in the standard.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 14, 11:06 pm, "Joe Smith" <unknown_kev_...@hotmail.com> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote:
> > On Apr 11, 10:41 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> >> Definition of large automatic arrays is one case where I've
> >> seen significant performance costs from
> >> zero-initialization. I know that some people use systems
> >> where it's not possible to define such arrays, but it is
> >> both feasible and commonplace in the code I work on.
> >> Removing all unneeded zero-initialization caused something
> >> like a 10% increase in the speed of one of my programs.

> > That's the traditional case.  But given current compiler
> > technology, I would imagine that in most cases, if the array
> > were really initialized before use, the compiler would be
> > able to detect it.  And of course, the compiler can forego
> > zero initialization anytime it detects that some other value
> > is written before the 0 is read.
>
> Perhaps, but quite possibly only when compiled with
> optimization. And compiling with optimization is not always
> possible. Now a small number of optimizations get applied even
> when optimizations are off in most compilers, but generally
> only those that could not be seen when stepping through the
> code in a debugger, and which don't require information only
> generated when optimizing. The sort of information this
> optimization would need would only be generated when
> optimizing.

Obviously, although the techniques aren't that complex.  Java
requires them in its compilers, remember.

> Therefore with gcc at least, every single program (when
> compiled without optimization) that declares variables that
> are not immediately initialized would run slower (than it
> currently does) if such a requirement were present in the
> standard.

If performance doesn't matter, who cares?  And if it does, use
optimization.  (I'm not sure, but I believe that some widely
used compilers already do zero initialize stack variables if
optimization isn't requested.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 14, 5:15 pm, James Kanze <james.ka...@gmail.com> wrote:
> > Perhaps, but quite possibly only when compiled with
> > optimization. And compiling with optimization is not always
> > possible. Now a small number of optimizations get applied even
> > when optimizations are off in most compilers, but generally
> > only those that could not be seen when stepping through the
> > code in a debugger, and which don't require information only
> > generated when optimizing. The sort of information this
> > optimization would need would only be generated when
> > optimizing.
>
> Obviously, although the techniques aren't that complex.  Java
> requires them in its compilers, remember.

If you mean the "no uninitialized locals" Java rule, then it's fairly
pessimistic, and gives false positives every now and then. Not to
mention that Java doesn't have to deal with pointers and references,
so the only place a local can be initialized is in the same scope;
it's much more complex for C++.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"James Kanze" <james.kanze@gmail.com> wrote in message
news:2e2461dc-656e-49c3-b8da-a9e683ea482d@r34g2000vba.googlegroups.com...

> Except that there are very, very few cases where it would make
> any difference.  The most obvious one is something like:
>     int i ;
>     std::cin >> i ;
> .  But in such cases, the cost of initializing i with 0 is
> negligeable compared to the cost of the >> operator.)

void foo() {
    struct { unsigned size; int array[10000]; } x;
    x.size = 0;
    // ...
}



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
....
> If performance doesn't matter, who cares?  And if it does, use
> optimization.  (I'm not sure, but I believe that some widely
> used compilers already do zero initialize stack variables if
> optimization isn't requested.)

Yes, I've used such a compiler, and the main reason why I'm aware of the
fact is that the zero-initialization caused several code defects to
produce reasonable results - we didn't recognize those defects until the
code was ported to a compiler where the garbage initialization produced
clearly unreasonable results.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 17, 1:16 am, "Andrew Koenig" <a...@acm.org> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message

> news:2e2461dc-656e-49c3-b8da-a9e683ea482d@r34g2000vba.googlegroups.com...

> > Except that there are very, very few cases where it would make
> > any difference.  The most obvious one is something like:
> >     int i ;
> >     std::cin >> i ;
> > .  But in such cases, the cost of initializing i with 0 is
> > negligeable compared to the cost of the >> operator.)

> void foo() {
>     struct { unsigned size; int array[10000]; } x;
>     x.size = 0;
>     // ...

> }

If that's the entire code, the compiler can recognize that
x.array is never used, and suppress it completely.  If it is
used in what replaces the //..., then whether the compiler can
suppress all or part of the initialization or not depends on how
it is used, and how smart the compiler is.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                  Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 17, 1:16 am, James Kuyper <jameskuy...@verizon.net> wrote:
> James Kanze wrote:

> ....

> > If performance doesn't matter, who cares?  And if it does,
> > use optimization.  (I'm not sure, but I believe that some
> > widely used compilers already do zero initialize stack
> > variables if optimization isn't requested.)

> Yes, I've used such a compiler, and the main reason why I'm
> aware of the fact is that the zero-initialization caused
> several code defects to produce reasonable results - we didn't
> recognize those defects until the code was ported to a
> compiler where the garbage initialization produced clearly
> unreasonable results.

If zero-initialization had been required by the language, those
wouldn't have been defects:-).  In the absense of such a
requirement, it's certainly better to initialize with some
easily identifiable value which would probably rarely be
"correct"---0xDEADBEEF is a classic value.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                  Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> On Apr 17, 1:16 am, James Kuyper <jameskuy...@verizon.net> wrote:
> > James Kanze wrote:
...
> > > If performance doesn't matter, who cares?  And if it does,
> > > use optimization.  (I'm not sure, but I believe that some
> > > widely used compilers already do zero initialize stack
> > > variables if optimization isn't requested.)
>
> > Yes, I've used such a compiler, and the main reason why I'm
> > aware of the fact is that the zero-initialization caused
> > several code defects to produce reasonable results - we didn't
> > recognize those defects until the code was ported to a
> > compiler where the garbage initialization produced clearly
> > unreasonable results.
>
> If zero-initialization had been required by the language, those
> wouldn't have been defects:-).

Actually, no - the numbers shouldn't have been set to zero. However,
the results when they were set to zero was insufficiently incorrect to
attract attention; the behavior when "randomly" initialized was not
only more likely to be seriously wrong, and therefore easily noticed,
but it also varied from run to run, which is the feature that actually
caught our attention.

Yes, better testing would have helped. For most of my programs, I'm
responsible for the scientific content of the product files; and the
way I would have validated such code would have involved  monitoring
every step in the calculation of a single value, to make sure that
each step made sense and produced the right result; that approach
would have caught this bug. However, for this particular program, I'm
only responsible for code maintenance, the accuracy of the scientific
content is another group's responsibility - they take a statistical
approach that overlooked the small errors caused by this bug.

> ... In the absense of such a
> requirement, it's certainly better to initialize with some
> easily identifiable value which would probably rarely be
> "correct"---0xDEADBEEF is a classic value.

Yes, that can be a useful approach. However, sometimes a "random"
value is more effective than a fixed one, because it makes it unlikely
for two consecutive tests with identical inputs to produce the same
result;.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 14, 7:15 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Apr 14, 11:06 pm, "Joe Smith" <unknown_kev_...@hotmail.com> wrote:
>
>
> > "James Kanze" <james.ka...@gmail.com> wrote:
> > > On Apr 11, 10:41 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> > >> Definition of large automatic arrays is one case where I've
> > >> seen significant performance costs from
> > >> zero-initialization. I know that some people use systems
> > >> where it's not possible to define such arrays, but it is
> > >> both feasible and commonplace in the code I work on.
> > >> Removing all unneeded zero-initialization caused something
> > >> like a 10% increase in the speed of one of my programs.
> > > That's the traditional case.  But given current compiler
> > > technology, I would imagine that in most cases, if the array
> > > were really initialized before use, the compiler would be
> > > able to detect it.  And of course, the compiler can forego
> > > zero initialization anytime it detects that some other value
> > > is written before the 0 is read.
>
> > Perhaps, but quite possibly only when compiled with
> > optimization. And compiling with optimization is not always
> > possible. Now a small number of optimizations get applied even
> > when optimizations are off in most compilers, but generally
> > only those that could not be seen when stepping through the
> > code in a debugger, and which don't require information only
> > generated when optimizing. The sort of information this
> > optimization would need would only be generated when
> > optimizing.
>
> Obviously, although the techniques aren't that complex.  Java
> requires them in its compilers, remember.
>
> > Therefore with gcc at least, every single program (when
> > compiled without optimization) that declares variables that
> > are not immediately initialized would run slower (than it
> > currently does) if such a requirement were present in the
> > standard.
>
> If performance doesn't matter, who cares?  And if it does, use
> optimization.  (I'm not sure, but I believe that some widely
> used compilers already do zero initialize stack variables if
> optimization isn't requested.)
>
> --
> James Kanze (GABI Software)             email:james.ka...@gmail.com
> Conseils en informatique orient   e objet/
>                     Beratung in objektorientierter Datenverarbeitung
> 9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34
>
> --
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@netlab.cs.rpi.edu]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]- Hide quoted text -
>
> - Show quoted text -

The elimination of code that the programmer never asked for is not
optimization. Optimization attempts to "do no harm" while preserving
expression behavior rather than "undo harm" it introduced on its own.
Plus, the programmer should not really have to get tied up with
options and suboptions to get the compiler to emit instructions
matching his/her expressions. One very special feature of C++ over
other languages is allowing the programmer to get as close to the
machine as possible without getting in the way. It's suitable for
interrupts, drivers, and many other high performance uses for that
reason, none of which benefit from gratuitous initialization.

A warning is clearly useful. After all, the compiler should be your
best friend, but not your mother. If the standard lumps warnings and
errors alike into "diagnostics" that may or may not stop code
generation, then perhaps THAT is an ambiguity the committee could
beneficially address with explicit distinction.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Rick Wheeler" <rwheeler@oyogeospace.com>
> A warning is clearly useful. After all, the compiler should be your
> best friend, but not your mother. If the standard lumps warnings and
> errors alike into "diagnostics" that may or may not stop code
> generation, then perhaps THAT is an ambiguity the committee could
> beneficially address with explicit distinction.

>From the standard's POW I'd be happy to have it included the syntax likle

int i = void;

or

int i = _NoInit; // some new keyword -- makes search way easier

certainly figured out for all kinds, including arrays, {} init, etc.

That construct would be well-formed, and have the same semantics as a
missing initializer.

Then the compiler could tell apart the intended noinits, and tuned by
options how to deal  with the rest.

But I guess it is too late for C++0x.    Suppose (by some magic) we had a
properly formed proposal before the next meeting -- what is the chance it
getting accepted?




--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]