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