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.

This info would be interesting to me, too.

My high school programming teacher said that when you declare variables, they contain whatever was left in them from the previous program. However, I'm not sure if that still applies with all computers/some computers/no computers, because his career ended pretty long ago.

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.

Mine always outputs 134518684 for ints (unsigned).

For A_ptr, the default constructor for A is invoked. This would default initialise the members, and thus the int member is zero initialised. As such, I believe that this is standard behaviour.

EDIT:
Oh wait, something is wrong with my reasoning. For a, the default constructor should be invoked, and this should result in the same behaviour as for A_ptr. hmm...

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.

Why is the constructor not called for automatic built-in types?


*edit* Googling got me this

Quote:

---

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.

Quote:

---

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 =).

Quote:

---

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.

Quote:

---

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

Quote:

---

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

---

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

Quote:

---

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.