Thread: initial values of data members of objects on the stack vs heap

Hi,
I noticed a strange behaviour when converting my code from dynamically allocating objects to declaring the objects on the stack. It seems that members in dynamically allocated objects are initialized to zero, while members of objects declared on the stack carry random values. Is it defined behaviour or is it implementation specific? (I observed this behaviour with GCC 4.1 on Linux)

I wrote a simple test program as an example.

Code:

#include <iostream>

using std::cout;
using std::endl;

class A {
        public:
                int x;
};

int main() {
        A *A_ptr = new A;
        cout << A_ptr->x << endl; //always prints "0"

        A a;
        cout << a.x << endl; //prints a different value every time
}

Thank you very much.

Try writing a program that takes up all the memory and fills it with zeroes. Close it, and immediately initialize your example program and see if it outputs more zeroes.

hmm, I don't know if I know how to write such a program. If you are referring to something like:

Code:

char *ptr;
while (ptr = malloc(sizeof(char))) {
     *ptr = 0;
}

last time I tried it, it crashed my computer =).

Oh, I understand: A is a POD type in "disguise" (I am more used to using struct instead of class for a POD struct). As such, x really is left uninitialised. I am wrong for A_ptr as well, in that case: that x is zero initialised is implementation defined, since its value is indeterminate in both cases.

I see. Thank you for clarifying.

Just as with malloc() the memory returned by new is not initialized; only static memory has a default initial value of zero.
from this: http://www.acm.org/crossroads/xrds1-1/ovp.html
which, it seems, is empirically disproved.

I am not sure if I got what the author meant. is static memory referring to the stack?

Thank you

Code:

int *ptr;
ptr = new int[5000];

A class that doesn't have a constructor will not have a "constructor call" - or at least, the constructor will not fill any of the data inside the class.

Any data on the stack will have random content when the function is entered, no matter if it's a class or some other data.

new is generally based on malloc (or at least, it's normally using the same underlying mechanisms), and whilst malloc isn't guaranteed to clear the allocated memory, it is normally how it works. I've also seen debug versions of malloc that fill memory with "0xCC" or "0xAA" or some such, to make it easier to identify when using un-initialized data (zero tends to be pretty common, so if something is zero, you don't really know if it was set to zero or just "happened to be zero").

It is definitely good practice to either have a constructor, or fill the data by hand after using malloc/new.

But in practice, both methods of getting memory for the object (on stack or via new), both leave x as "undefined".

--
Mats

int *ptr;
ptr = new int[5000];

it doesn't change anything on my system (still random values)

A class that doesn't have a constructor will not have a "constructor call" - or at least, the constructor will not fill any of the data inside the class.

Any data on the stack will have random content when the function is entered, no matter if it's a class or some other data.

new is generally based on malloc (or at least, it's normally using the same underlying mechanisms), and whilst malloc isn't guaranteed to clear the allocated memory, it is normally how it works. I've also seen debug versions of malloc that fill memory with "0xCC" or "0xAA" or some such, to make it easier to identify when using un-initialized data (zero tends to be pretty common, so if something is zero, you don't really know if it was set to zero or just "happened to be zero").

It is definitely good practice to either have a constructor, or fill the data by hand after using malloc/new.

But in practice, both methods of getting memory for the object (on stack or via new), both leave x as "undefined".

Thank you for the information. I was expecting both methods to produce undefined memory (from what I read somewhere else), but was surprised that gcc's implementation of new actually zeros the memory. Thank you for clarifying.