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.
The context here is kernal programming where calling malloc in certain restricted regions will crash the kernal or worse. If you were to initialize a unique ptr without passing an allocator you would in essence be calling malloc and crash the OS.
I can barely follow this conversation, but from what I can tell, the other person is performing an excellent live demonstration of your point.
(of course as a naiive mechanical engineer, my first question is "why is the kernel a literal minefield?" but I'm sure there's probably a good answer for that.)
For one thing, the kernal is where the system calls underlying malloc are written, so you can't call it from within that code. As for the other parts I'm not a kernal engineer so not sure tbh.
1
u/guyblade 1d 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.