Re: Am I right here?

From: Leor Zolman (
Date: 01/22/04

Date: Thu, 22 Jan 2004 18:49:09 GMT

On Thu, 22 Jan 2004 18:06:45 GMT, Thomas Matthews
<> wrote:

>Leor Zolman wrote:
>> Modern compilers IMO are going to do pretty much the same thing in all
>> these cases. The distinctions come out when you ask these kinds of
>> questions about instances of classes with non-trivial c'tors and
>> assignment operators, where you end up doing "extra work" when you
>> instantiate (default construct?) in one place, then assign in a
>> different statement, but for primitive types it's all academic.
>Actually, the two cases are different. The first is zero-initialized
>variables and the second is assignment during execution.

Yup, I should have qualified "pretty much the same thing" by adding
"with respect to performance." (that's what I was thinking).

Your detail below is excellent information to have, however.

>Many compilers will create a table of variables that need to be
>initialized (or place them in a separate region). The run-time
>initialization code will zero-out each variable in the table
>or in the case of a region, set the entire region to zeros. One
>of the big differences between the two are _when_ the assignment
>takes place. Global variables are initialzed before the main()
>function is executed.
>As far as efficiency goes, that is up to the compiler and
>platform. Some platforms have instructions that can set
>regions of memory to a given value. On some platforms,
>a multi-byte variable which has a value of zero, many
>not have each byte assigned to zero. There is no guarantee.
>Also, the execution time saved by either method may not
>be significant (i.e. 1 millisecond gain) as apposed to
>making an algorithm more efficient (more than one ms.)
>or removing a requirement (big gain).
>Optimization is relative, and should only be performed
>when the need arises. For example, an embedded system
>should only be optimized for space when the code doesn't
>fit into the available Read Only Memory space (most of
>the time, the H/W folk are not willing to put in
>larger devices, due to cost and work involved). However,
>quality and robustness are far more important, IMHO.

Leor Zolman
BD Software -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
           Decryptor at

Relevant Pages

  • Re: Thou shalt have no other gods before the ANSI C standard
    ... > I thought that most compilers worked this way. ... No. Static data that is not explicitly initialized ... On some platforms that means that either the compiler ... which do *not* have default initialization. ...
  • Re: C to Fortran?
    ... real variables to be initialised to zero. ... Compilers I'm familiar with apply that switch only to SAVEd scalar variables. ... Unless you have a translator with an option to perform an equivalent translation, you face the same problem when you translate to another language. ... Default zero initialization was never provided by Fortran, although certain compilers did it "most of the time." ...
  • Re: Bugs at my web site
    ... > implicit save and initialization to zero?.... ... initialization to zero, then, sorry, but you aren't going to convince me ... It's not just new compilers that are at issue either. ...
  • Re: Detect EOF for direct access, unformatted files?
    ... > compilers on almost as many platforms over many years, ... > *never* encountered a system which returns zero for a record beyond ... $ gfc filesize.f ...
  • Re: "Default construction" of built-in types?
    ... Comment could have been extended to say "on other compilers, platforms, etc.." ... given that I didn't know if the initialization to zero was standard. ...