C++ Using RAII with Polymorphism and Stack Allocation [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 9 years ago.

Improve this question

I have been researching into RAII (http://tomdalling.com/blog/software-design/resource-acquisition-is-initialisation-raii-explained/) and have a number of questions!

1. There are some strong arguments for initialising objects on the stack. Is there ever a good scenario to allocate memory on the heap?

2. How does this work with polymorphic objects? For example, you have an abstract base class called Biome and you need a container of biomes. This container needs to store objects of Ocean, Tundra, Desert etc. Are there any issues or strong arguments against allocating these objects on the stack, but then storing pointers to these objects in a container of pointer to Biome? I am aware that once the encapsulating objects go out of scope, these objects will be destroyed and their pointers will be addressed to memory which potentially does not exist.

Answer 1

There are some strong arguments for initializing objects on the stack. Is there ever a good scenario to allocate memory on the heap?

You certainly need to allocate objects in the heap when the number of objects or their actual type is known only at runtime (not at compile time) or when it is large. You don't want to have large call stack frames (a typical frame should be less than a kilobyte, since the entire stack is less than two megabytes and you could have recursive, or simply very deep, functions).

How does this work with polymorphic objects? For example, you have an abstract base class called Biome and you need a container of biomes. This container needs to store objects of Ocean, Tundra, Desert etc.

Your container will in fact store pointers to these objects. Of course, you may want to have smart pointers.

Answer 2

1. No. RAII is based on automatic object destruction, i.e. on destructor calls automatically inserted by your compiler. (Edit: I hope your question was only about heap+RAII, not heap in general!)

2. Not very well. Polymorphmic classes are often unsuitable for RAII in my experience, because object lifetime of objects of polymorphmic classes often does not correspond to scope. RAII is only truly RAII if lifetime corresponds 100% to scope.

Here are three possible scenarios for your example:

First progam logic: The objects know themselves when they die, reacting on external events. In this case, they notify their container about their demise and then call delete this.

Second program logic: The container manages their lifetime, in which case the container would call delete on every element in its destructor:

for (auto element : m_elements) {
    delete element;
}

(in C++11 syntax)

Third program logic: The objects are owned by various different components, not only the container, and they should die only when the last of those components dies. In this case, you may find std::shared_ptr (or boost::shared_ptr in pre-C++11) useful.

The point is: None of these scenarios have anything to do with RAII, really, because in each of them, lifetime does not correspond to scope.