Question

Possible Duplicate:
Does this type of memory get allocated on the heap or the stack?

I have a few memory-related questions, I was hoping you guys would be able to answer. Consider this code, with Foo representing a large class with lots of methods and lots of primitive data members:

class Foo {
  public:
    Foo() : // Initialize all data members ...
        { }

    // Lots of methods ...

    ~Foo() { /*Nothing needed here ... correct?*/ }

private:
    int    a;
    int    b;
    char   c;
    double d;
    // Lots of other primitive data members (no pointers) ...
};

class Bar {
  public:
    void func() {
        foo = new Foo();
    }

    // Assuming Bar::func() is always called before deletion ...
    ~Bar() { delete foo; }
  private:

    Foo* foo;
};

int main() {
    Bar bar;
    bar.func();

    Bar* barptr;
    barptr->func();

    return 0;
}

My question is, when I call bar.func(), are all the data members of Foo allocated on the stack memory or on the heap memory (I know foo would be on the heap…I think!)? What about when I call barptr->func()? Is, for example, Foo::a on the stack or on the heap?

Furthermore, do I need to explicitly delete anything in Foo::~Foo()? Foo only has primitive local data members, and none of the functions use new or malloc().

In the case that I have absolutely no idea what I’m talking about, I’d appreciate it if someone could explain where these data are stored.

Answer 1

Everything allocated with new is on the heap, including all its members. The line foo = new Foo(); creates a Foo (including all its members) on the heap.
Only named objects are on the stack. In your case bar (a Bar), and barptr (a pointer to a Bar).
Foos destructor doesn’t need to do anything, which is actually quite common, if you use RAII properly, like is the C++ way.

In your main function, bar is a region on the stack that is a Bar, which allocates a Foo on the heap. If barptr; were actually initialized, barptr would be a region on the stack that is a pointer to a Bar somewhere (maybe stack maybe not). However, in every case, a Bars foo member will be allocated on the heap, since that’s what Bars constructor tells it to do.

In your main function, bar is a region on the stack that is a (pointer to a (large collection of primitives)), which allocates a (large collection of primitives) on the heap.
If barptr; were actually initialized, barptr would be a region on the stack that is a pointer to a (pointer to a (large collection of primitives)) somewhere (maybe stack maybe not). However, in every case, the (large collection of primitives) will be allocated on the heap, since that’s what the constructor tells it to do.

Since I know someone will mention it, the heap/stack distinction is at the compiler’s whim, and not standardized in any way. It is fully allowed to “cheat” and put things in other places if it feels like it. For instance, global objects are frequently on neither the stack nor the heap, but in another place. Also, that’s how C# and java go so fast despite the frequent (apparent) use of memory management. The compiler frequently “cheats” and puts “dynamically scoped” objects on the stack.