1

There are three kinds of memory: static memory (static variables/members, global variables), stack, and heap.

The definition of global variables is variables defined outside of any functions.

I am wondering about the code below,

#include<iostream>
int *test=new int[5]();
int main(){
  return 0;
}

It could be compiled and run. But what I am wondering is, where is that array allocated? Is it a global variable on the heap?

C++ Primer says that global variables will be freed when the program finishes. My question is, does this happen even if they are on the heap?

trincot
  • 317,000
  • 35
  • 244
  • 286
zijianz
  • 19
  • 3

1 Answers1

1

The pointer test is just some variable (of pointer type). It is allocated in the static part of the memory, however what it points to (i.e. memory for 5 ints) is some chunk of memory allocated on the heap. The latter won't be automatically de-allocated. The memory used to store the pointer test (most commonly 4 or 8 bytes, depending on the machine) will indeed be marked as available at program termination, but not what the pointer points to. To convince yourself, try this:

#include <iostream>

struct Foo
{
    Foo()
    {
        std::cout << "Foo()" << std::endl;
    }
    ~Foo()
    {
        std::cout << "~Foo()" << std::endl;
    }
};

Foo* pFoo = new Foo; // no automatic destructor call at exit, memory/resource leak

// destructor is called below, as Foo (and not Foo*) is now global 
// (and not a pointer-to-Foo that has no destructor, thanks @Konrad Rudolph)
Foo foo; 

int main()
{

}
vsoftco
  • 55,410
  • 12
  • 139
  • 252
  • http://stackoverflow.com/questions/2204608/does-c-call-destructors-for-global-and-class-static-variables disagrees with your answer. – Richard Chambers Apr 04 '15 at 23:21
  • @Richard That’s different and doesn’t apply here. `*pFoo` isn’t a global object — `pFoo` is! And C++ would absolutely call `pFoo`’s destructor, if it had one. But pointer types have no destructor (`Foo` has one, `Foo*` hasn’t). – Konrad Rudolph Apr 04 '15 at 23:25
  • @KonradRudolph exactly, good addition, that's what I meant to say. The "pointed-to" memory is not the object itself. I hoped I made it clear in the answer though. – vsoftco Apr 04 '15 at 23:25
  • @KonradRudolph, thanks for the clarification, that makes sense. It would be exactly like having a raw pointer on the stack which is then assigned the address of an object and when the pointer goes out of scope the raw pointer variable disappears however the object allocated on the heap is not leading to a memory leak, something that `unique_ptr` and its siblings is designed to deal with in C++11. So what happens if instead of `new` you used `unique_ptr` with `make_unique`? Though I suppose there would not be much point in that except for unique circumstances of special resources. – Richard Chambers Apr 05 '15 at 12:04
  • @RichardChambers On the contrary, I think using a `unique_ptr` here is probably quite often a useful thing. At any rate, `unique_ptr` has a regular destructor that would be called at the end of the runtime, and this destructor in turn invokes the pointee’s destructor. – Konrad Rudolph Apr 05 '15 at 12:31