Stack, Heap, and pointer question.

[CGunn86]

I've been doing some reading, and testing around a bit on my own, but wanted some more confirmation on what's going on here. I'm gonna do my best to write this up and explain this.

Let's say I have a Class A, it's contents are irrelevant for this example, so we just have Class A. NOW, we have Class B, which carries 3 Class A objects being allocated on the heap using unique_ptr's.

Class B
{
public:
  ClassB();
  ~ClassB();

private:
  std::unique_ptr<ClassA> m_obj1;
  std::unique_ptr<ClassA> m_obj2;
  std::unique_ptr<ClassA> m_obj3;
}

Alright, easy enough. Now I'm going to pretend that ClassB is our "main game" class that holds our game loop functions, our input processings, our window creation, etc, etc, it's our game. So our main.cpp looks like this

int main(int argc, char* argv[])
{
	std::unique_ptr<ClassB> game = std::make_unique<ClassB>(//Whatever we pass to our constructor); 

So here is my question. Because we're creating our "main class/game" object on the heap also using a uniquite_ptr, does it really make any sense to create those 3 objects of type ClassA on the heap as well using pointers? Wouldn't those 3 objects still be created on the heap because the object they're a part of <ClassB> is being created on the heap?

In otherwords, let's say our ClassB looked like this instead...

Class B
{
public:
  ClassB();
  ~ClassB();

private:
  ClassA m_obj1;
  ClassA m_obj2;
  ClassA m_obj3;
}

Notice the only difference between these two examples of ClassB is the method in which we use to declare our 3 objects. The first one creates them on the heap using smart pointers (unique_ptr), while this second example creates those objects on the stack by just creating them. BUT the class they're being used in is being created on the heap.

So ultimately it makes no difference which method we use in THIS example, right?

Sorry if this was a bit long winded, worded badly, and explained poorly. But thanks for any and all input.

[Flaze07]

yes, there is a difference...one of them is on the stack, and the other is on the heap...so..even if the class they are in are created on the heap, I am pretty sure the member would be created in the stack

[Uk Marine]

Hello, you are correct, when creating an object on the heap, all the data members of said object are automatically on the heap. You do not have to assign them with unique_ptr<> or the new keyword. If you do manually allocate them then they would be allocated on a different part of the heap.

[CGunn86]

Someone else on the learnprogramming reddit said the exact opposite, so I decided I'd post here at a place solely focused on C++

I'm creating a simple 2d engine for a pong like game I'm making with the help of SDL2 and just wanted to figure this out before the project gets too big and I end up shooting myself in the foot down the road.

[Uk Marine]

@Flaze07, No, if you allocate an object on the heap, then all its content are also stored on the heap.

[Uk Marine]

Just to be clear, if an object is instantiated on the heap, then all the data members are automatically on the heap without having to assign them with "new".

EDIT: or unique_ptr<>

[CGunn86]

@UK Marine
Thanks for clearing that up. That coincides with the other information I've gathered. So in theory the proper thing to do here would be to just create those member objects locally, rather than dynamically with new or the use of a smart pointer, right? Since I'm gonna end up creating the whole base object they're inside on the heap anyways.

[Uk Marine]

Sure, the space allocated to the object on the heap will be large enough to accommodate all of its data members.

[Peter87]

Do you really care if they are stored on the heap or not? What's usually more relevant is their storage duration.


Member variables and local function variables has automatic storage duration. This means they will automatically be destroyed when the parent object is destroyed or when going out of scope. This is often the preferred way unless you have special needs because it is handled automatically and is less error prone.

Objects that are created with new or std::make_unique have dynamic storage duration and are located on the heap. This gives you more control over when the object is going to be constructed and destroyed. It has some overhead and often makes the code more complicated so it should only be used when necessary.

Note that objects with automatic storage duration can also be located on the heap if they are part of an object with dynamic storage duration.


In your situation I would use automatic storage duration (your second approach) if ClassB always contains exactly three objects of exactly the type ClassA. If some of them can be null, or they can point to objects that are derived from ClassB, or you want to be able to transfer ClassB objects between ClassA objects without copying them, only then I would use dynamic storage duration (your first approach).

[MikeyBoy]

Peter87 makes some good points. You should think about ownership. Which entity in your code owns those ClassA objects? Who is responsible for creating them? What is responsible for deleting them? When are they created, and when are they deleted?

[Repeater]

Your first code example, here:

Class B
{
public:
  ClassB();
  ~ClassB();

private:
  std::unique_ptr<ClassA> m_obj1;
  std::unique_ptr<ClassA> m_obj2;
  std::unique_ptr<ClassA> m_obj3;
}

You say

we have Class B, which carries 3 Class A objects being allocated on the heap using unique_ptr's

but this class doesn't carry any Class A objects. Creating an object of type B will NOT create any class A objects. maybe you understand this and you misspoke, but it's worth checking.

[Peter87]

Creating an object of type B will NOT create any class A objects

It depends on how the constructor is implemented.

[Repeater]

Okey dokey, I'll thrash the dead horse. Creating a unique_ptr to an object does not automatically create an object for it to point to.