C++ Allocating memory on the heap and stack?

Question

Coming from a Java background, I'm still a little confused about allocating memory in C++. I'm pretty sure the first two statements are correct:

void method() {
    Foo foo;    // allocates foo on the stack, and the memory is freed
                // when the method exits
}

void method2() {
    Foo *foo = new Foo();   // allocates foo on the heap
    delete foo;             // frees the memory used by foo
}

But what about something like this?

void method3() {
    Foo foo = *new Foo();   // allocates foo on the heap, and then copies it to the stack?
                            // when the method exits, the stack memory is freed, but the heap memory isn't?
}

Say I added foo to a global array inside method3(). If I tried to access one of foo's data members after the method exits, would that work? And is method3() prone to memory leaks?

Thanks in advance.

Foo foo(); actually doesn't allocate anything. It declares a function. — Qaz
– Qaz, Commented Feb 24, 2013 at 7:08

Alok Save · Accepted Answer · 2013-02-24 07:14:53Z

10

Foo foo();

Declares a function by the name foo which returns a Foo object and does not take any arguments. It is known as the most vexing parse in C++. You probably meant:

Foo foo;

It creates a foo object locally/automatic storage. The object is automatically deallocated once the scope { } in which it is declared ends.

Foo *foo = new Foo();   // allocates foo on the heap
delete foo;

This is true, the object on freestore pointed by foo is deallocated once you call delete. There is no memory leak.

 Foo foo = *new Foo();

Allocates a Foo object on freestore and then a copy of that object is used to initialize foo. Since you do not have a pointer to the freestore allocated object, it causes a memory leak. Note that if the destructor of Foo has some code which causes side effects then it is not merely memory leak but undefined behavior.

answered Feb 24, 2013 at 7:14

Alok Save

207k56 gold badges448 silver badges539 bronze badges

Sign up to request clarification or add additional context in comments.

12 Comments

nebulabrot Over a year ago

I meant Foo foo() to call the no argument constructor for class Foo. But you're right, I'll change it in the question to avoid confusion.

Alok Save Over a year ago

@nebulabrot: Foo foo; does that, not Foo foo();

CygnusX1 Over a year ago

@Alok Save: Saying that "standard says so" is most unhelpful answer. Which line of the standard says so? Are you sure that for every definition of Foo you will hit that standard issue?

CygnusX1 Over a year ago

I answered it myself by visiting: stackoverflow.com/questions/9920973/…

CygnusX1 Over a year ago

I could completely omit the "number of scenarios" statement and still ask a perfectly valid question about which element of the standard leads to the undefined behavour. Sadly you were not compelled to answer it, but I found it myself :) As for concrete scenario example: above code will be completely fine if the constructor of Foo has a side effect of registering itself in some global set of created objects (and destructor - deregistering). That sort of simple management would prevent any memory leak of Foo in the above examples. Another example could include overloaded new operator for Foo...

|

Collectives™ on Stack Overflow

C++ Allocating memory on the heap and stack?

1 Answer 1

12 Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

12 Comments

Linked

Related