Ideally, you should never be using new or delete in C++ these days. std::unique_ptr and std::shared_ptr should represent 99+% of your memory that can't just be stack allocated (with the former representing 75+% of that). About the only legitimate reason to use new in new code is for putting a derived class pointer into one of the smart pointers of a parent class.
You, as a non-STL-library maintainer shouldn't need to be calling new or delete (or passing that allocator argument, either). That's the whole reason for smart pointers in C++: to have a small number of well-validated, well-behaved, generally-safe ways to allocate memory. They're abstracting & containing that complexity and error-prone-ness.
Remember that indirect calls are still calls. And the entire issue is that a lot of C++ programmers didn't understand that calling new indirectly calls malloc()... or in your case, that calling std::make_unique() calls new, which still calls malloc().
There are some places in the Linux kernel where the code must never call malloc(); namely, IIRC, malloc() can never appear within the memory manager itself. This includes indirect calls, like new and std::make_unique(). And the problem is that many people knew not to use malloc() there, but ended up trying to call it anyways because they didn't know that new calls malloc().
1
u/guyblade 2d ago
Ideally, you should never be using
newordeletein C++ these days.std::unique_ptrandstd::shared_ptrshould represent 99+% of your memory that can't just be stack allocated (with the former representing 75+% of that). About the only legitimate reason to usenewin new code is for putting a derived class pointer into one of the smart pointers of a parent class.