Reputation: 547
Lately, I learned there is a consensus among C++ programmers that the new
, delete
and delete[]
operators should be avoided as often as possible, as already discussed here, here or here. While searching, I even stumbled upon an April Fools' joke stating that these operators would become deprecated in C++20.
I happen to write and maintain a C/C++ program, written in such language in order to carry on useful libraries and classes written by other programmers. As it must run in quite limited environments (i.e., old Linux distributions with the bare minimum in terms of programs), I can't rely on features brought C++11 and later versions (such as smart pointers), and I sticked so far to a mix of C and Java programming habits while expanding my program. Among others, I used quite often dynamic allocation with new
and delete
- which sounds, of course, to be a problem.
To ease the maintenance of my code by future programmer(s), I would like to minimize dynamic allocation with said keywords in my code. The problem is that my program has to manage some quite large data structures used for (almost) the entire execution. As a consequence, I struggle to figure out why I should avoid dynamic allocation in these situations.
To simplify, consider I have a data structure (modeled as an object) worth 10 Megaoctets which is used for the entire execution of the program and which the size in memory can increase over time. My questions are the following:
Is dynamic allocation of the object with new
still a bad practice in this particular context ? What are the better alternatives ?
Suppose now I instantiate somewhere in my program a new object without using new
, do some operations on it which could slightly change its size, then use a method to insert it in my data structure. How does it work, memory-wise, if automatic allocation (as mentioned here) is used ?
Many thanks in advance.
Upvotes: 1
Views: 584
Reputation: 1841
You could try using boost smart pointers.
https://www.boost.org/doc/libs/1_71_0/libs/smart_ptr/doc/html/smart_ptr.html
They are very similar to the C++ 11 smart pointers, but available as a library which should work in pre C++ 11 environments. If you decide to go this way, you may also want to look at this
How to include only BOOST smart pointer codes into a project?
Now, I'm wondering if you are confusing the new/delete functions with dynamic allocation in general. Smart Pointers are still dynamic allocation, however they are able to clean themselves up so that you don't have to remember too. That's why they are preferred over using new/delete (malloc/free, etc), they are much less likely to lead to memory leaks.
Automatic allocation is fine when the object lifespan allows it, but if you need the object to persist outside of the function it was declared in, you'll need dynamically allocated memory.
Upvotes: 1
Reputation: 27577
Is dynamic allocation of the object with
new
still a bad practice in this particular context?
Yes, it's bad to have a new
in your code mainly because of memory leaks if delete
or delete[]
isn't called, especially in the face of exceptions.
What are the better alternatives?
Write smart pointers and have them either call new
themselves or be called with a new
expression:
myUniquePtr<myObj> obj_ptr(new myObj);
and then use RAII to have their destructors call delete
or delete[]
.
Make your smart pointer behave as naked pointer in every other way (overload operator->
etc). Then it'll work in your code with the same syntax as your raw pointers did without having to worry about whether a heap object is deleted at the end of a it's life-cycle no matter what paths the code can take.
Upvotes: 0