Thread: How are structs initalized to zero?

Global variables are ALWAYS initialized to zero by the compiler [unless you initialize it differently in your source-code], in the sense that they are stored in a region that will be filled with zeros. If you add your own initialization, e.g.

Code:

// myheader.h:

struct testStruct
{
    char myChar;
    int myInt;
    char array[200];
} myStruct = { 17, 3400, "John Smith" };

then by most likelyhood it will also move to "initialized data", so where the compile fills it with the relevant data.

--
Mats

That's one thing I've never quite understood. Why are global variables initialized to 0, but not normal variables? If C doesn't initialize to make code faster, why not leave globals uninitialized also?

Originally Posted by cpjust

That's one thing I've never quite understood. Why are global variables initialized to 0, but not normal variables? If C doesn't initialize to make code faster, why not leave globals uninitialized also?

Because it's a one-time initialization - local variables are created and destroyed every time the function is called. So the compiler lets you do the work when and as you need it, rather than filling everything with zero, and then you initialize it with something else anyways. If you have Visual Studio, you can compare the time it takes in a debug build with a release build. Sure there are other things - so do a release build with the lowest level of optimization, and compare that. You will probably find that there is a factor 3-4 in performance difference. Most of that is because Visual Studio's debug runtime fills local variables with 0xCC - which takes a lot of extra time.

--
Mats

But couldn't the app start faster if it didn't initialize global variables? You'd think they'd take all the speed optimizations they can get...

Originally Posted by cpjust

But couldn't the app start faster if it didn't initialize global variables? You'd think they'd take all the speed optimizations they can get...

Filling 1MB of RAM with zeros takes about 40ns * 1024 * 1024 / 16 seconds - that is about 2.5 milliseconds (that is the time to actually write it to memory, not the time it takes to write it to the cache - that is faster). I don't think you care if your application startup time is 2.5ms faster or not. It will take about 4 times longer if your hard-disk is just a little fragmented and the hard-disk head has to seek to another track to get one block of the executable file loaded.

And it happens ONCE at startup (and one MB of data is quite a bit)

Finally, if you don't fill it with zero's, it needs filling with something else, since we do not want an applicaiton starting to be able to find our credit card number, love-letters to secret lover, or whatever else may have been left around in the memory from another application that just exited. So the memory needs to be filled with something - it doesn't take more or less time to fill it with zero compared to filling it with random gunk or something else that has some sort of meaning. Zero does make more sense than random gunk, since it allows some sort of predictability, and we don't need to fill our data with zero in the code itself.

--
Mats

That brings me to a possibly useful tip. You can avoid the time spent 0xCC filling stack variables by using constructor initialisation lists rather than assignment, and of course using construction instead of assigment in the calling code.
I find this helps debug build code run closer to the speed of release build code.
It's essentialy bypassing the uninitialised state of a variable by giving it a value as it comes into existence, instead of after.

Unfortunately C doesn't have constructors, and if you have to declare variables at the top of the scope you don't always have anything to initialize them with.

That brings me to a possibly useful tip. You can avoid the time spent 0xCC filling stack variables by using constructor initialisation lists rather than assignment, and of course using construction instead of assigment in the calling code.
I find this helps debug build code run closer to the speed of release build code.
It's essentialy bypassing the uninitialised state of a variable by giving it a value as it comes into existence, instead of after.

That's probably something you should do anyway. If this were C++. (But we're in the C forum, so it probably isn't.)

It's a little surprising to me that the compiler doesn't optimize assignments in constructors into initialization. I guess we're talking about debug mode here, though.

Originally Posted by dwks

It's a little surprising to me that the compiler doesn't optimize assignments in constructors into initialization. I guess we're talking about debug mode here, though.

Indeed - and it's not so much about "doesn't optimize", but rather that you may want to improve the chances of finding that nasty bug caused by not initializing member variable blah in your constructor, which once every 4 weeks causes the applicaton to crash randomly, because at that particular point, it doesn't do the same thing that it usually does, and so on and so forth.

I'm a tiny bit surprised it actually helps in any way in debug mode, because I think the way it works is that the compiler fills all the local stack space with 0xCC (or similar), when it enters the function - so as long as the stack-space is being used up, it will be filled with 0xCC at all times - no matter how/where the constructions/initialization is done - I could be wrong, I haven't looked at the code. I have found it very useful to find certain kinds of errors, including in our rather large production code at work.

--
Mats

Originally Posted by matsp

Filling 1MB of RAM with zeros takes about 40ns * 1024 * 1024 / 16 seconds - that is about 2.5 milliseconds (that is the time to actually write it to memory, not the time it takes to write it to the cache - that is faster). I don't think you care if your application startup time is 2.5ms faster or not. It will take about 4 times longer if your hard-disk is just a little fragmented and the hard-disk head has to seek to another track to get one block of the executable file loaded.

And it happens ONCE at startup (and one MB of data is quite a bit)

Finally, if you don't fill it with zero's, it needs filling with something else, since we do not want an applicaiton starting to be able to find our credit card number, love-letters to secret lover, or whatever else may have been left around in the memory from another application that just exited. So the memory needs to be filled with something - it doesn't take more or less time to fill it with zero compared to filling it with random gunk or something else that has some sort of meaning. Zero does make more sense than random gunk, since it allows some sort of predictability, and we don't need to fill our data with zero in the code itself.

--
Mats

I'm not saying it's a bad thing that it zero initializes global variables; it's just surprising, since C is built for performance in every other way.

Originally Posted by cpjust

I'm not saying it's a bad thing that it zero initializes global variables; it's just surprising, since C is built for performance in every other way.

Yes, but it's also about usability - and in MANY cases, the data would have to zero initialized anyways. The difference with local variables is mostly that the memory they use is recycled from previous function calls [most of the time], and that is what causes the overhead when it needs to be done EVERY function call - and by the way, C is by no means unique in this aspect - nearly all Algol-related languages have "undefined content of local variables" - it's for speed reasons, but it's much more because you have to fill the functions local variables EVERY time the function is called.

Filling global variables once is very small overhead. Filling local variables each time the function is called is a significant overhead.

--
Mats