About adoption of implicit zero initialisation of POD types in theC++ standard

Discussion in 'C++' started by Ioannis Vranos, Apr 9, 2009.

  1. What argument can 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
     
    Ioannis Vranos, Apr 9, 2009
    #1
    1. Advertising

  2. Ioannis Vranos

    red floyd Guest

    Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    Ioannis Vranos wrote:
    > What argument can 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?
    >


    1. You don't pay for what you don't use.
    2. C compatibility.
     
    red floyd, Apr 9, 2009
    #2
    1. Advertising

  3. Ioannis Vranos

    Bo Persson Guest

    Re: About adoption of implicit zero initialisation of POD types in the C++ standard

    Ioannis Vranos wrote:
    > What argument can 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?


    You don't pay for what you don't use.

    If C++ had initialization for all C style data, the net would be full
    of benchmarks "proving" that C++ is slow and bloated.



    Bo Persson
     
    Bo Persson, Apr 9, 2009
    #3
  4. Ioannis Vranos

    Kai-Uwe Bux Guest

    Re: About adoption of implicit zero initialisation of POD types in the C++ standard

    Bo Persson wrote:

    > Ioannis Vranos wrote:
    >> What argument can 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?

    >
    > You don't pay for what you don't use.
    >
    > If C++ had initialization for all C style data, the net would be full
    > of benchmarks "proving" that C++ is slow and bloated.


    I doubt that. If the initial value of the variable is not used (which it
    shouldn't in the case of an uninitialized variable), in the vast majority
    of cases the optimizer of the compiler will be able to detect that an can
    optimize away the initialization. If the initial value is used, then you
    only pay for what you use :)


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Apr 9, 2009
    #4
  5. Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    What about requiring all compilers provide a specific compiler switch for zero-itinialisation of all POD
    types, or a specific #pragma directive?
     
    Ioannis Vranos, Apr 9, 2009
    #5
  6. Ioannis Vranos

    Bo Persson Guest

    Re: About adoption of implicit zero initialisation of POD types in the C++ standard

    Ioannis Vranos wrote:
    > What about requiring all compilers provide a specific compiler
    > switch for zero-itinialisation of all POD types, or a specific
    > #pragma directive?


    The standard doesn't require any compiler switches. In fact, it
    doesn't even require the use of a compiler - only an "implementation"
    of the language.

    The original (=current) standard made a huge effort to only define ONE
    language, which everyone should implement. That's the general idea of
    having a standard - ONE standard. Not a set of features you can pick
    and choose from.

    On the other hand, the upcoming standard has some "conditionally
    supported" features. Perhaps this could have been one of those?



    Bo Persson
     
    Bo Persson, Apr 9, 2009
    #6
  7. Ioannis Vranos

    peter koch Guest

    Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    On 9 Apr., 17:23, Kai-Uwe Bux <> wrote:
    > Bo Persson wrote:
    > > Ioannis Vranos wrote:
    > >> What argument can 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?

    >
    > > You don't pay for what you don't use.

    >
    > > If C++ had initialization for all C style data, the net would be full
    > > of benchmarks "proving" that C++ is slow and bloated.

    >
    > I doubt that. If the initial value of the variable is not used (which it
    > shouldn't in the case of an uninitialized variable), in the vast majority
    > of cases the optimizer of the compiler will be able to detect that an can
    > optimize away the initialization. If the initial value is used, then you
    > only pay for what you use :)


    Maybe today, but that was not the case when C++ was born. I vaguely
    remember that performance was the explicit argument by Stroustrup in
    one of his writings - perhaps in a direct porting of C-code. But I
    have no reference for this, and it could be a slip of my mind.

    /Peter
     
    peter koch, Apr 9, 2009
    #7
  8. Ioannis Vranos

    peter koch Guest

    Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    On 9 Apr., 19:06, "Bo Persson" <> wrote:
    > Ioannis Vranos wrote:
    > > What about requiring all compilers provide a specific compiler
    > > switch for zero-itinialisation of all POD types, or a specific
    > > #pragma directive?

    >
    > The standard doesn't require any compiler switches. In fact, it
    > doesn't even require the use of a compiler - only an "implementation"
    > of the language.
    >
    > The original (=current) standard made a huge effort to only define ONE
    > language, which everyone should implement. That's the general idea of
    > having a standard - ONE standard. Not a set of features you can pick
    > and choose from.
    >
    > On the other hand, the upcoming standard has some "conditionally
    > supported" features. Perhaps this could have been one of those?


    On the third hand why make such a fuss about it. It should be built
    into the cortex of every C++ programmer, that every variable is
    initialised on first use. Writing int i should cause a slight sweat to
    occur, making you initialise i right away or at least in the very next
    sentence.

    /Peter
     
    peter koch, Apr 9, 2009
    #8
  9. Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    peter koch wrote:
    >
    > On the third hand why make such a fuss about it. It should be built
    > into the cortex of every C++ programmer, that every variable is
    > initialised on first use. Writing int i should cause a slight sweat to
    > occur, making you initialise i right away or at least in the very next
    > sentence.
    >
    > /Peter



    What about oversights? This is the way bugs can be introduced, and this is the problem the initialisation
    checks of POD types aim to solve.


    --
    Ioannis A. Vranos

    C95 / C++03 Developer

    http://www.cpp-software.net
     
    Ioannis Vranos, Apr 9, 2009
    #9
  10. Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    Ioannis Vranos wrote:
    > peter koch wrote:
    >>
    >> On the third hand why make such a fuss about it. It should be built
    >> into the cortex of every C++ programmer, that every variable is
    >> initialised on first use. Writing int i should cause a slight sweat to
    >> occur, making you initialise i right away or at least in the very next
    >> sentence.
    >>
    >> /Peter

    >
    >
    > What about oversights? This is the way bugs can be introduced, and this
    > is the problem the initialisation checks of POD types aim to solve.



    Perhaps the best solution to this, is not zero-initialisation, but compiler errors, when POD types are not
    initialised.


    --
    Ioannis A. Vranos

    C95 / C++03 Developer

    http://www.cpp-software.net
     
    Ioannis Vranos, Apr 9, 2009
    #10
  11. Ioannis Vranos

    James Kanze Guest

    Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    On Apr 9, 5:35 pm, Jeff Schwab <> wrote:
    > blargg wrote:
    > > Ioannis Vranos wrote:
    > >> What argument can 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?


    > > Unnecessary initialization, paying for something you don't
    > > need?


    > I recall reading that an always-initialize-everything model
    > was tried in Java, and rejected specifically because it had a
    > serious impact on performance. Five minutes of Googling do
    > not turn up anything I can cite for that, though.


    > The Java solution is for the compiler to perform static
    > analysis, and generate a diagnostic if the value of any local
    > variable is used without prior initialization. In C++, this
    > is a QoI issue; in g++, for example, the flag -Wuninitialized
    > (enabled by -Wall) enables similar behavior.


    It's a bit more complicated than that. "Objects" in Java (using
    the Java definition of an object) are initialized to 0. It's
    only local variables which aren't, and the reason can't be
    performance---if the compiler can determine that the variable is
    assigned to before being written (required at present to
    determine whether the program is legal), it could easily skip
    the 0 initialization, even if the standard said otherwise.

    --
    James Kanze (GABI Software) email:
    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
     
    James Kanze, Apr 9, 2009
    #11
  12. Ioannis Vranos

    James Kanze Guest

    Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    On Apr 9, 7:43 pm, peter koch <> wrote:
    > On 9 Apr., 17:23, Kai-Uwe Bux <> wrote:
    > > Bo Persson wrote:
    > > > Ioannis Vranos wrote:
    > > >> What argument can 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?


    > > > You don't pay for what you don't use.


    > > > If C++ had initialization for all C style data, the net
    > > > would be full of benchmarks "proving" that C++ is slow and
    > > > bloated.


    > > I doubt that. If the initial value of the variable is not
    > > used (which it shouldn't in the case of an uninitialized
    > > variable), in the vast majority of cases the optimizer of
    > > the compiler will be able to detect that an can optimize
    > > away the initialization. If the initial value is used, then
    > > you only pay for what you use :)


    > Maybe today, but that was not the case when C++ was born. I
    > vaguely remember that performance was the explicit argument by
    > Stroustrup in one of his writings - perhaps in a direct
    > porting of C-code. But I have no reference for this, and it
    > could be a slip of my mind.


    Performance was the motivation in C. Today, any compiler worth
    its salt could optimize it out most of the time, but if I'm not
    mistaken, the original C compiler fit in 16KB, and there's a
    serious limit to how much intelligence you can build into 16KB.

    C++ just took over the C rules, without really asking any
    questions.

    --
    James Kanze (GABI Software) email:
    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
     
    James Kanze, Apr 9, 2009
    #12
  13. Ioannis Vranos

    James Kanze Guest

    Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    On Apr 9, 8:41 pm, Ioannis Vranos <> wrote:
    > peter koch wrote:


    > > On the third hand why make such a fuss about it. It should
    > > be built into the cortex of every C++ programmer, that every
    > > variable is initialised on first use. Writing int i should
    > > cause a slight sweat to occur, making you initialise i right
    > > away or at least in the very next sentence.


    > What about oversights? This is the way bugs can be introduced,
    > and this is the problem the initialisation checks of POD types
    > aim to solve.


    One of the motivations (not the only one, I think) for allowing
    variables to be defined anywhere, instead of just at the top of
    the block, is that it eliminates almost all cases where you
    might want to declare a variable without initializing it. The
    results are that in C++, the lack of an initializer sticks out:
    it simply doesn't get through code review.

    --
    James Kanze (GABI Software) email:
    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
     
    James Kanze, Apr 9, 2009
    #13
  14. Ioannis Vranos

    James Kanze Guest

    Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    On Apr 9, 10:30 pm, Jeff Schwab <> wrote:
    > Ioannis Vranos wrote:
    > > Ioannis Vranos wrote:
    > >> peter koch wrote:


    > >>> On the third hand why make such a fuss about it. It should
    > >>> be built into the cortex of every C++ programmer, that
    > >>> every variable is initialised on first use. Writing int i
    > >>> should cause a slight sweat to occur, making you
    > >>> initialise i right away or at least in the very next
    > >>> sentence.
    > >> What about oversights? This is the way bugs can be
    > >> introduced, and this is the problem the initialisation
    > >> checks of POD types aim to solve.


    > > Perhaps the best solution to this, is not
    > > zero-initialisation, but compiler errors, when POD types are
    > > not initialised.


    > Mandating such a check would break an awful lot of existing
    > code.


    Only code that was already broken.

    > Even initializing previously pseudo-random memory can cause
    > devastating soft errors, e.g. the Debian/Valgrind/OpenSSL
    > fiasco.


    > http://metasploit.com/users/hdm/tools/debian-openssl/


    If I understand correctly, the code in question depended on some
    sort of random initialization of the data in order to
    "randomize" some value. This rates as one of the most stupid
    techniques I can think of. If you need a random value, there
    are well established procedures for getting one. (Under Linux,
    I'll seed a random number generator with values read from
    /dev/random, and use it.)

    > Basically, peter koch is right about this. Any uninitialized
    > variable should give rise to perspiration.


    The whole point of the "error initialization" is to increase the
    chances of testing finding the use of the uninitialized value.

    > IMHO, even non-const variables should have a darned good
    > reason for not being const, and that reason usually ought to
    > be commented. (The obvious exception is a loop index.)


    The obvious exception is anything that is going to modified:).

    --
    James Kanze (GABI Software) email:
    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
     
    James Kanze, Apr 9, 2009
    #14
  15. Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    blargg wrote:
    > Ioannis Vranos wrote:
    >> Ioannis Vranos wrote:
    >>> peter koch wrote:
    >>>> On the third hand why make such a fuss about it. It should be built
    >>>> into the cortex of every C++ programmer, that every variable is
    >>>> initialised on first use. Writing int i should cause a slight sweat to
    >>>> occur, making you initialise i right away or at least in the very next
    >>>> sentence.
    >>> What about oversights? This is the way bugs can be introduced, and this
    >>> is the problem the initialisation checks of POD types aim to solve.

    >> Perhaps the best solution to this, is not zero-initialisation, but compiler
    >> errors, when POD types are not initialised.

    >
    > struct X { int i, j; };
    >
    > void f( X* );
    >
    > int g()
    > {
    > X x;


    Here the implementation would issue the diagnostic.


    > f( &x ); // should compiler issue diagnostic?


    Not here.

    > return x.i; // should compiler issue diagnostic?


    Not here:


    > }
    >
    > Consider possible implementations of f, in another compilation unit:
    >
    > void f( X* x )
    > {
    > x->i = 1;
    > }



    Speaking strictly, any uninitialised POD type would issue a diagnostic, so the function definition becomes:

    void f( X* x= something ) // It passes the initialisation check
    {
    x->i = 1;
    }


    void f( X* x ) // Given the above, we would get a diagnostic here
    > {
    > x->i++;
    > }
    >
    > (and your lines still exceed 80 characters by a longshot)



    We have large monitor resolutions these days. Are you using some DOS newsgroup reader?



    --
    Ioannis A. Vranos

    C95 / C++03 Developer

    http://www.cpp-software.net
     
    Ioannis Vranos, Apr 10, 2009
    #15
  16. Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    Jeff Schwab wrote:
    > Ioannis Vranos wrote:
    >> blargg wrote:

    >
    >>> (and your lines still exceed 80 characters by a longshot)

    >>
    >>
    >> We have large monitor resolutions these days. Are you using some DOS
    >> newsgroup reader?

    >
    > If you break your lines at something greater
    > than
    > about 72 characters, many mail clients will
    > break
    > them again. The result is jagged lines that
    > are
    > aesthetically displeasing. 80 columns is
    > the
    > standard for source code files, but on
    > usenet
    > 72 is really the maximum you should ever
    > use
    > (if you care about your readers'
    > experience),
    > and prefer 68 where feasible.
    >
    > Re. the large monitor resolutions, not all of us have the eyesight to
    > squint at a bunch of tiny fonts. Please, just follow the conventions,
    > and we'll all get along fine.



    72 characters ain't enough these days. I have set my newsgroup reader to 110 characters, which is also
    relatively limited.



    --
    Ioannis A. Vranos

    C95 / C++03 Developer

    http://www.cpp-software.net
     
    Ioannis Vranos, Apr 10, 2009
    #16
  17. Ioannis Vranos

    Bo Persson Guest

    Re: About adoption of implicit zero initialisation of POD types in the C++ standard

    blargg wrote:
    > Ioannis Vranos wrote:
    >> Ioannis Vranos wrote:
    >>> peter koch wrote:
    >>>>
    >>>> On the third hand why make such a fuss about it. It should be
    >>>> built into the cortex of every C++ programmer, that every
    >>>> variable is initialised on first use. Writing int i should cause
    >>>> a slight sweat to occur, making you initialise i right away or
    >>>> at least in the very next sentence.
    >>>
    >>> What about oversights? This is the way bugs can be introduced,
    >>> and this is the problem the initialisation checks of POD types
    >>> aim to solve.

    >>
    >> Perhaps the best solution to this, is not zero-initialisation, but
    >> compiler errors, when POD types are not initialised.

    >
    > struct X { int i, j; };
    >
    > void f( X* );
    >
    > int g()
    > {
    > X x;
    > f( &x ); // should compiler issue diagnostic?
    > return x.i; // should compiler issue diagnostic?
    > }
    >


    This is where a C++ developer starts to sweat, because she is forced
    to interface with this old C style code.

    In real C++ it would at least be

    X f();

    const X x = f();


    (Using silly names X, x, and f to protect the guilty).



    Bo Persson
     
    Bo Persson, Apr 10, 2009
    #17
  18. Ioannis Vranos

    highegg Guest

    Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    On Apr 9, 3:18 pm, Ioannis Vranos <> wrote:
    > What argument can 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


    Here's a specific practical concern:
    It is not always desirable to initialize at allocation.
    For instance, GNU Octave uses its Array class as a base for array
    manipulation. It would be great to rebase the class on STL vector (to
    take advantage of its automatic memory allocation, optional bounds
    checking etc), but the primary obstacle is that there is no way you
    can get an uninitialized vector, or, more precisely, a valid pointer
    to it's uninitialized data (if you call reserve(), then it actually
    works, but it's not guaranteed).
    There are many instances within Octave where you allocate the memory
    for an external library (BLAS, LAPACK, FFTW etc) which is supposed to
    initialize it. Of course there is not even the slightest hope a
    compiler can optimize out the redundant initialization in such a case
    (which would occur if POD types were always initialized), because it
    simply can't tell whether the external routine needs it. The impact is
    usually quite small but measurable, sometimes negligible, sometimes
    noticeable.
    The only workaround left would be to use malloc rather than new, which
    is certainly possible but brings all sorts of secondary problems.
     
    highegg, Apr 10, 2009
    #18
  19. Ioannis Vranos

    James Kanze Guest

    Re: About adoption of implicit zero initialisation of POD types inthe C++ standard

    On Apr 10, 12:04 am, Jeff Schwab <> wrote:
    > James Kanze wrote:
    > > On Apr 9, 5:35 pm, Jeff Schwab <> wrote:
    > >> blargg wrote:
    > >>> Ioannis Vranos wrote:
    > >>>> What argument can 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?


    > >>> Unnecessary initialization, paying for something you don't
    > >>> need?


    > >> I recall reading that an always-initialize-everything model
    > >> was tried in Java, and rejected specifically because it had
    > >> a serious impact on performance. Five minutes of Googling
    > >> do not turn up anything I can cite for that, though.


    > >> The Java solution is for the compiler to perform static
    > >> analysis, and generate a diagnostic if the value of any
    > >> local variable is used without prior initialization. In
    > >> C++, this is a QoI issue; in g++, for example, the flag
    > >> -Wuninitialized (enabled by -Wall) enables similar
    > >> behavior.


    > > It's a bit more complicated than that. "Objects" in Java
    > > (using the Java definition of an object) are initialized to
    > > 0. It's only local variables which aren't,


    > Thought that was what I said...


    Yes, but the general discussion (concerning C++) seemed broader,
    at least to me. In Java, local variables are either pointers or
    basic types; in C++, you have a lot more possibilities, and
    "default initialization" can be a lot more complicated.

    > > and the reason can't be performance---if the compiler can
    > > determine that the variable is assigned to before being
    > > written (required at present to determine whether the
    > > program is legal), it could easily skip the 0
    > > initialization, even if the standard said otherwise.


    > Not so. To run on the JVM, you have to make it past the Java
    > byte-code verifier. If the verifier required all local
    > variables to be initialized before access, then compilers
    > could not elide such initialization, even if they knew it were
    > safe to do so. The designers of Java made a conscious
    > decision not impose such a requirement, for reasons of
    > performance IIRC.


    I don't know what the motivation of the Java designers was. All
    I know was that performance doesn't make sense as a motivation
    (which doesn't mean that it wasn't the motivation). Had the
    designers required zero initialization, and dropped the
    requirements for definite assignment, the compilers could have
    generated exactly the same code as they do today---if your code
    met the requirements of definite assignment, then the compiler
    could detect it (since it is required today to detect it), and
    drop the zero initialization. If your code didn't, then
    according to today's rules, you would have to add an artificial
    initialization, which shouldn't cost anything less (and could
    cost more) than the compiler generated zero initialization. If
    there is any difference in performance (and in most cases, I
    don't think there will be), then requiring zero initialization
    by the compiler will be faster than requiring definite
    assignment.

    --
    James Kanze (GABI Software) email:
    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
     
    James Kanze, Apr 10, 2009
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ajax Chelsea

    Is array of POD still a POD type?

    Ajax Chelsea, Dec 1, 2003, in forum: C++
    Replies:
    1
    Views:
    346
    Ron Natalie
    Dec 1, 2003
  2. Zhiqiang Ye
    Replies:
    53
    Views:
    10,273
    Dan Pop
    Jun 28, 2004
  3. Tim Clacy
    Replies:
    8
    Views:
    395
    Tim Clacy
    May 30, 2006
  4. Ioannis Vranos
    Replies:
    2
    Views:
    285
    Ian Collins
    Apr 17, 2009
  5. Himanshu Garg
    Replies:
    1
    Views:
    166
    Himanshu Garg
    Sep 21, 2003
Loading...

Share This Page