Since C++11 as established standard we have the Dynamic memory management facilities aka smart pointers.
Even from earlier standards we have the c++ standard Containers library as a good replacement for raw arrays (allocated with new T[]).
Question(s) in bold:
Let aside the placement new override, is there any valid use case that can't be achieved using smart pointers or standard containers but only using new and delete directly (besides implementation of such container/smart pointer classes of course)?
It's sometimes rumored that using new and delete handrolled can be "more efficient" for certain cases. Which are these actually? Don't these edge cases need to keep track of the allocations the same way as standard containers or smart pointers need to do?
Regarding interaction with 3rd party libraries:
Assumed a 3rd party library returns raw pointers allocated with new like
MyType* LibApi::CreateNewType() { return new MyType(someParams); } you can always wrap that to a smart pointer to ensure that delete is called:
std::unique_ptr<MyType> foo = LibApi::CreateNewType(); even if the API requires you to call their legacy function to free the resource like
void LibApi::FreeMyType(MyType* foo); you still can provide a deleter function:
std::unique_ptr<MyType, LibApi::FreeMyType> foo = LibApi::CreateNewType(); I'm especially interested in valid "every day" use cases, which aren't covered by the mentioned standard facilities.
That new and delete may be used in memory management / garbage collector frameworks or standard container implementation is out of question1.
1)Add.: Regarding that last paragraph, this should be a clear indicator that new and delete isn't for beginner c++ students, but should be left for the more advanced courses.
18 Answers
Answers 1
When ownership should not be local.
As an example, a pointer container may not want ownership over the pointers in it to reside in the pointers themselves.
If you try to write a linked list with forward unique ptrs, at destruction time you can easily blow the stack.
A vector like container of owning pointers may be better suited to storing delete operation at the container or subcobtainer level, and not at the element level.
In those and similar cases, you wrap ownership like a smart pointer does, but you do it at a higher level. Many data structures (graphs, etc) may have similar issues, where ownership properly resides at a higher point than where the pointers are, and they may not map directly to an existing container concept.
In some cases it may be easy to factor out the container-ownership from the rest of the data structure. In others it may not.
Sometimes you have insanely complex non local non reference counted lifetimes. There is no sane spot to put the ownership pointer in those cases.
Determining correctness here is hard, but not impossible. Programs that are correct and have such complex ownership semantics exist.
All of these are corner cases, and few programmers should run into them more than a handful of times in a career.
Answers 2
I'm going to be contrarian, and go on record as saying "no" (at least to the question I'm pretty sure you really intended to ask, for most of the cases that have been cited).
What seem like obvious use-cases for using new and delete (e.g., raw memory for a GC heap, storage for a container) really aren't. For these cases, you want "raw" storage, not an object (or array of objects, which is what new and new[] provide respectively).
Since you want raw storage, you really need/want to use operator new and operator delete to manage the raw storage itself. You then use placement new to create objects in that raw storage, and directly invoke the destructor to destroy the objects. Depending on the situation, you might want to use a level of indirection to that though--for example, the containers in the standard library use an Allocator class to handle these tasks. This is passed as a template parameter, which provides a customization point (e.g., a way to optimize allocation based on a particular container's typical usage pattern).
So, for these situations, you end up using the new keyword (in both the placement new and the invocation of operator new), but not something like T *t = new T[N];, which is what I'm pretty sure you intended to ask about.
Answers 3
One valid use case is having to interact with legacy code. Especially if passing raw pointers to functions that take ownership of them.
Not all libraries you use may be using smart pointers and to use them you may need to provide or accept raw pointers and manage their lifetimes manually. This may even be the case within your own codebase if it has a long history.
Another use case is having to interact with C which does not have smart pointers.
Answers 4
The OP specificly asks about how/when handrolling will be more efficient in an everyday use case - and I will address that.
Assuming a modern day compiler/stl/platform, there is not an every day use where handrolled use of new and delete will be more efficient. For the shared_ptr case i believe it will be marginal. In an extremely tight loop(s) there could be something to gain by just using raw new to avoid the ref counting (and find some other method of cleaning up - unless somehow imposed on you, you choose to use shared_ptr for a reason), but that is not an everyday or common example. For the unique_ptr there is not actually any difference, so i think it is safe to say that it is more of rumour and folklore and that performance wise it will not actually matter at all (difference will not be measurable in normal cases).
There are cases where it is not desirable or possible to use a smart pointer class as already covered by others.
Answers 5
Some APIs might expect you to create objects with new but will take over ownership of the object. The Qt library for example has a parent-child model where the parent deletes its children. If you use a smart pointer, you are going to run into double-deletion issues if you're not careful.
Example:
{ // parentWidget has no parent. QWidget parentWidget(nullptr); // childWidget is created with parentWidget as parent. auto childWidget = new QWidget(&parentWidget); } // At this point, parentWidget is destroyed and it deletes childWidget // automatically. In this particular example, you can still use a smart pointer and it will be fine:
{ QWidget parentWidget(nullptr); auto childWidget = std::make_unique<QWidget>(&parentWidget); } because objects are destroyed in reverse order of declaration. unique_ptr will delete childWidget first, which will make childWidget unregister itself from parentWidget and thus avoid double-deletion. However, most of the time you don't have that neatness. There are many situations where the parent will be destroyed first, and in those cases, the children will get deleted twice.
In the above case, we own the parent in that scope, and thus have full control of the situation. In other cases, the parent might not be hours, but we're handing ownership of our child widget to that parent, which lives somewhere else.
You might be thinking that to solve this, you just have to avoid the parent-child model and create all your widgets on the stack and without a parent:
QWidget childWidget(nullptr); or with a smart pointer and without a parent:
auto childWidget = std::make_unique<QWidget>(nullptr); However, this will blow up in your face too, since once you start using the widget, it might get re-parented behind your back. Once another object becomes the parent, you get double-deletion when using unique_ptr, and stack deletion when creating it on the stack.
The easiest way to work with this is to use new. Anything else is either inviting trouble, or more work, or both.
Such APIs can be found in modern, non-deprecated software (like Qt), and have been developed years ago, long before smart pointers were a thing. They cannot be changed easily since that would break people's existing code.
Answers 6
For simple use cases, smart pointers, standard containers and references should be enough to use no pointers and raw allocation and de-allocation.
Now for the cases I can think about:
- development of containers or other low-level concepts - after all the standard library itself is written in C++ and it does make use of raw pointers, new and delete
- low level optimization. It should never be a first class concern, because compilers are smart enough to optimize standard code, and maintainability is normally more important than raw performance. But when profiling shows that a block of code represents more than 80% of the execution time, low level optimization makes sense, and thats on of the reasons why the low level C standard library is still a part of C++ standards
Answers 7
Another possible valid use case is when you code some garbage collector.
Imagine that you are coding some Scheme interpreter in C++11 (or some Ocaml bytecode interpreter). That language requires you to code a GC (so you need to code one in C++). So ownership is not local, as answered by Yakk. And you want to garbage collect Scheme values, not raw memory!
You probably will end up using explicit new and delete.
In other words, C++11 smart pointers favor some reference counting scheme. But that is a poor GC technique (it is not friendly with circular references, which are common in Scheme).
For example, a naive way of implementing a simple mark-and-sweep GC would be to collect in some global container all the pointers of Scheme values, etc...
Read also the GC handbook.
Answers 8
When you have to pass something across the DLL boundary. You (almost) can't do that with smart pointers.
Answers 9
Another use case may be 3rd party library returning raw pointer which is internally covered by own intrusive reference counting (or own memory management - which is not covered by any API/user interface).
Good example is OpenSceneGraph and their implementation of osg::ref_ptr container and osg::Referenced base class.
Although it may be possible to use shared_ptr, the intrusive reference counting is way better for scene graph like use cases.
Personally I do see anything "smart" on the unique_ptr. It is just scope locked new & delete. Although shared_ptr looks way better, it requires overhead which is in many practical cases unacceptable.
So in general my use case is:
When dealing with non-STL raw pointer wrappers.
Answers 10
You can still use new and delete if we want to create our own lightweight memory allocation mechanism. For example
1.Using In-Place new : Generally used for allocating from preallocated memory;
char arr[4]; int * intVar = new (&arr) int; // assuming int of size 4 bytes 2.Using Class Specific Allocators : If we want a custom allocator for our own classes.
class AwithCustom { public: void * operator new(size_t size) { return malloc(size); } void operator delete(void * ptr) { free(ptr); } }; Answers 11
3 common examples where you have to use new instead of make_...:
- If your object doesn't have a public constructor
- If you want to use a custom deleter
- If you are using c++11 and want to create an object that is managed by a unique_ptr (athough I'd recommend writing your own
make_uniquein that case).
In all those cases however, you'd directly wrap the returned pointer into a smart pointer.
2-3 (probably not so common) examples, where you wouldn't want/can't to use smart pointers:
- If you have to pass your types through a c-api (you are the one implementing
create_my_objector implement a callback that has to take a void*) - Cases of conditional ownership: Think of a string, that doesn't allocate memory when it is created from a string litteral but just points to that data. Nowerdays you probably could use a
std::variant<T*, unique_ptr<T>>instead, but only if you are ok with the the information about the ownership being stored in the variant and is you accept the overhead of checking which member is active for each access. Of course this is only relevant if you can't/don't want to afford the overhead of having two pointers (one owning and one non-owning)- If you want to base your ownership on anything more complex than a pointer. E.g. you want to use a gsl::owner so you can easily query it's size and have all the other goodies (iteration, rangecheck...). Admittedly, you'd most likely wrap that in your own class,so this might fall into the category of implementing a container.
Answers 12
another example that has not already been mentioned is when you need to pass an object through a legacy (possibly asynchronous) C-callback. Usually, these things take a function pointer and a void* (or an opaque handle) to pass some payload upon. As long as the callback gives some guarantee on when/how/how many times it will be invoked, resorting to a plain new->cast->callback->cast->delete is the most straightforward solution (ok, the delete will be probably managed by a unique_ptr on callback site, but the bare new is still there). Of course, alternative solutions exist, but always requires the implementation of some sort of explicit/implicit 'object lifetime manager' in that case.
Answers 13
You sometimes have to call new when using private constructors.
Say you decide to have a private constructor for a type that is intended to be called by a friend factory or an explicit create method. You can call new inside this factory but make_unique won't work.
Answers 14
The primary use case where I still use raw pointers is when implementing a hierarchy that uses covariant return types.
For example:
#include <iostream> #include <memory> class Base { public: virtual ~Base() {} virtual Base* clone() const = 0; }; class Foo : public Base { public: ~Foo() override {} // Case A in main wouldn't work if this returned `Base*` Foo* clone() const override { return new Foo(); } }; class Bar : public Base { public: ~Bar() override {} // Case A in main wouldn't work if this returned `Base*` Bar* clone() const override { return new Bar(); } }; int main() { Foo defaultFoo; Bar defaultBar; // Case A: Can maintain the same type when cloning std::unique_ptr<Foo> fooCopy(defaultFoo.clone()); std::unique_ptr<Bar> barCopy(defaultBar.clone()); // Case B: Of course cloning to a base type still works std::unique_ptr<Base> base1(fooCopy->clone()); std::unique_ptr<Base> base2(barCopy->clone()); return 0; } Answers 15
Adding to other answers, there are some cases where new/delete make sense -
- Integrating with a 3rd party library which returns the raw pointer and expect you return the pointer to the library once you are done (The library has its own memory management functionality).
- Working on resource constrained embedded device where memory (RAM/ROM) is a luxury (even a few kilobytes). Are you sure you want to add more runtime (RAM) and compiled (ROM/Overlay) memory requirement to your application or you want to program carefully with new/delete?
- From purist point of view, in some cases smart pointers won't work intuitively (due to their nature). For example, for builder pattern you should to use reinterpret_pointer_cast, if you are using smart pointers. Another case is where you need to cast from a base type to a derived type. You put yourself danger if you get the raw pointer from smart pointer, cast it and put it in another smart pointer and ended up freeing the pointer multiple times.
Answers 16
There is still a chance to use malloc/free in C++, as you can use new/delete, and anything higher level wrapping the STL memory templates provided.
I think in order to really learn C++ and especially understand the C++11 memory templates you should create simple structures with new and delete. Just to better understand how they work. All the smart pointer classes rely on those mechanisms. So if you understand what new and delete does, you are going to appreciate the template more and really find smart ways to use them.
Today I personally try to avoid them as much as possible, but one main reason is the performance, which you should care if it is critical.
These are my rules of thumb I always have in mind:
std::shared_ptr: Automatic management of pointers but due to the reference counting it uses for tracing the accessed pointers, you have a worse performance every time you access these objects. Compared simple pointers I would say 6 times slower. Keep in mind, you can use get() and extract the primitive pointer, and continue accessing it. Of you must be careful with that one. I like to as that as a reference with *get(), so the worse performance is not really a deal.
std::unique_ptr The pointer access may only happen at one point in the code. Because this template forbids copy, thanks to the r-references && feature, it is much faster than an std::shared_ptr. Because there is still some ownership overhead in this class I would say, they are about twice as slow as a primitive pointer. You access the object than the primitive pointer within that template. I also like to use reference trick here, for less required accesses to the object.
About performance, it might be true, that those templates are slower, but keep in mind that if you want to optimize software, you should profile first and see what really takes many instructions. It is very unlikely that smart-pointers are the problem, but sure it depends on your implementation.
In C++ no one should care about malloc and free, but they exist for legacy code. They differ basically in the fact, that they know nothing about c++ classes, which with new and delete operator case is different.
I use std::unique_ptr and std::shared_ptr in my project Commander Genius everywhere and I'm really happy that they exist. I have not to deal with memory leaks and segfaults since then. Before that, we had our own smart-pointer template. So for productive software, I cannot recommend them enough.
Answers 17
One of the problem I deal with is mining big data structures for hardware design and language analysis with few hundred million elements. Memory usage and performance is a consideration.
Containers are a good convenient way to quickly assemble data and work with it, but the implementation uses extra memory and extra dereferences which affect both, the memory and performance. My recent experiment with replacing smart pointers with a different custom implementation provided about 20% performance gain in a verilog preprocessor. Few years ago I did compare custom lists and custom trees vs vectors/maps and also saw gains. The custom implementations rely on regular new/delete.
So, new/delete are useful in high-efficiency applications for custom designed data structs.
Answers 18
When you want to create multidimensional arrays but aren't familiar with C++11 syntax like std::move, or aren't familiar with writing custom deleters for smart pointers.
0 comments:
Post a Comment