What is the best way to put large objects on the heap? - c++

Question

I am working on a project that needs to load many objects from a data file and store them in memory. Since I have been told that stack space is rare and larger amounts of data should be on the heap I put everything on the heap. However, my impression is that I overdid it a little bit.
My current design looks like this:
class RoadMap
{
unique_ptr<set<unique_ptr<Node>>> allNodes;
void addNode(unique_ptr<Node> node)
{
this->allNodes->insert(std::move(node));
}
}
int main()
{
unique_ptr<RoadMap> map(new RoadMap());
// open file etc.
for (auto nodeData : nodesInFile)
{
map->addNode(unique_ptr<Node>(new Node(nodeData)));
}
}
From what I understand by now, this creates a lot of overhead because there are many unique pointers involved that I think I do not need. If I understand correctly, it should be sufficient to only have one unique pointer barrier in the "pointer chain". However, I am unsure what the best practice is to do this.
Option 1
class RoadMap
{
unique_ptr<set<Node>> allNodes;
void addNode (Node node)
{
this->allNodes->insert(node);
}
}
int main()
{
RoadMap map;
//open file etc.
for (auto nodeData : nodesInFile)
{
map.addNode(Node(nodeData));
}
}
The advantage of this seems to me that the RoadMap class itself is the only one that needs to take care of heap allocation and does so only once when creating the set.
Option 2
class RoadMap
{
set<Node> allNodes;
void addNode (Node node)
{
this->allNodes.insert(node);
}
}
int main()
{
unique_ptr<RoadMap> map(new RoadMap());
// open file etc.
for (auto nodeData : nodesInFile)
{
map->addNode(Node(nodeData));
}
}
Here the unique pointer is only in the main function meaning that the users of the RoadMap class will need to know that this object can become quite large and should be put on the stack. I don't think that this is an overly nice solution.
Option 3
class RoadMap
{
set<unique_ptr<Node>> allNodes;
void addNode(unique_ptr<Node> node)
{
this->allNodes.insert(std::move(node));
{
}
int main()
{
RoadMap map;
// open file etc.
for (auto nodeData : nodesInFile)
{
map.addNode(unique_ptr<Node>(new Node(nodeData)));
}
}
This solution uses many unique pointers which means that when deleting the RoadMap many destructors and deletes will need to be called. Also the RoadMap caller has to supply a unique_ptr when adding a node meaning that he has to do the heap allocation himself.
Right now, I am favouring option 1 over the others. However, I have only been coding C++ for a comparatively short time and am unsure whether I fully understand the concepts behind memory management which is why I want you to (in)validate my opinion. Am I correct in assuming that option 1 is the best way to do this? Do you have any additional references to best practices for this sort of thing?

Answer 1

Give Node a move constructor and move assignment operator (to make operations on the set cheap), then use a mix of option 1 and 2. std::set will already be heap allocating its contents so you don't need to worry about allocating a RoadMap on the heap. Note the extra std::move inside addNode to allow Nodes to be moved into the set.
class RoadMap
{
set<Node> allNodes;
void addNode (Node node)
{
allNodes.emplace(std::move(node));
}
};
int main()
{
RoadMap map;
// open file etc.
for (const auto& nodeData : nodesInFile)
{
map.addNode(Node(nodeData));
}
}

Answer 2

Each of them are quite different from each other.
I would suggest option 2 for simplicity. But it might be more performance intensive in some operations like sort etc because you would be moving the entire Node and not a pointer to it.
I assume that is not a problem, since you are using set. You can still optimize this by using move semantics on your Node object. With out this you are still using 1 copy per add.
The above issue I mention might have been a problem with vector. Another issue you would have with storing the objects directly is the lack of polymorphism. You cant store subtypes of Node, they would get sliced.
If this is an issue I would suggest option 2. Storing pointers means that moving them is faster, and Polymorphism works.
I see no reason for Option 1 or your original solution.
p.s. the this-> in your code is unnecessary.
p.p.s As DyP points out set uses heap anyway, which is what makes Option 2 good. Clue - Stack based structures cannot grow. => Only std::array is I believe stored on stack.

Answer 3

Let me talk a little about the meta problem: You don't want the stack to overflow and hence put your data structures on the heap. That's the right thing to do. But the important thing to understand here is when things will be put onto the heap.
Every local variable is allocated on the stack. If you have data structures of dynamic size, then they refer to the heap in (allmost) all cases. (The only exception I know is when you reserve memory on the stack on purpose with alloca() or std::get_temporary_buffer() or something like it). In particular all STL containers keep their memory on the heap and hardly any stack memory for local variables or member variables is used (except std::array whose size is known at compile-time).
Hence wrapping dynamically sized data structures into unique_ptrs has very little effect, if you want to save stack memory, but it adds indirection to your program which complicates your code, slows down execution and increases heap memory usage unnecessarily.
Here's an example: On Visual Studio 2010 with 32-bit compilation an std::set will use 20 bytes of memory on the stack independent of the template type parameter and of the actual number elements contained in the set. The memory for the set elements is on the heap.
I believe, that you can now make your own decision on whether to use unique_ptrs for the purpose you intent.

Answer 4

Basically it also depends how you want to access the stored Node instances inside your RoadMap instance. I assume your Node instance will release the wrapped note data.
I would go for an adjusted version 2.