'new' in modern c++

[homing]

Until now I've always used smart pointers instead of dynamic allocation with new, because in every modern / and even older books (with other libraries) it's adviced to use smart pointers instead of raw pointers, but is there really no use of new in modern C++ where C++11 / 14 is available?

It's being said that C++ 'advantage' (one of many) vs Java/C# is the memory management, because Java/C# use GC which cause some overhead. This overhead can be significant for Games or performance critical software. But aren't smart pointers some kind of GC? So this argument would be nonsense.

Can anyone help me?

[Cubbi]

Yes, there is no good use for new in application code, see CppCoreGuidelines rule R.11 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-r11-avoid-calling-new-and-delete-explicitly

I've used more placement new (which itself is very rare) than plain new in the last five or so years (and before that all of my news were immediately consumed by smart pointer constructors)

Smart pointers are not any kind of GC, they are an ownership tracking system ( https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rr-owner ). If ownership is known, there is no garbage, and there is no need for GC to execute, consuming CPU time and possibly halting threads, to examine every object on the heap to determine whether it still has an owner. A C++ program using unique_ptr knows that with no runtime effort.

it is possible to misuse std::shared_ptr as a "GC replacement", by programming as if in a GC-enabled language, but using shared_ptr for every object reference. That is both counter to its purpose and results in greater overhead than a similar Java program. Personally, I find it very rare that std::shared_ptr is useful at all.

[homing]

so the argument: manual memory managment is actually nonsense, c++ allows it, but you shouldn't do it manually and instead use smart_pointers.

[Thomas1965]

You can use smart_pointers when when you write an application from scratch and have a modern compiler. If you have to work with legacy code you might end up to have to use new or even malloc, calloc etc.

[MikeyBoy]

so the argument: manual memory managment is actually nonsense, c++ allows it, but you shouldn't do it manually and instead use smart_pointers.

"Nonsense" is overstating it. You can use manual memory management, and if you can't use C++11 or Boost, you'll have to do that, or else write your own smart pointer classes (which amounts to much the same thing). Even in C++11, you'll have to call new to create objects, before handing the raw pointer over to a smart pointer, because the various make_* functions that wrap that up don't come in until C++14, IIRC.

Plenty of good code has been written using manual memory management.

It's just that, when you have smart pointers available, it's safer and simpler to use them.

[Peter87]

MikeyBoy wrote:

Even in C++11, you'll have to call new to create objects, before handing the raw pointer over to a smart pointer, because the various make_* functions that wrap that up don't come in until C++14, IIRC.

std::make_shared was added in C++11.
std::make_unique was added in C++14.

[MikeyBoy]

Ah, OK - thanks for the correction :)

Of course, as Cubbi said, shared_ptr is less useful than unique_ptr, so that would seem to be a silly order in which to add those functions to the standard.

[Peter87]

I think make_shared was added first because it allows it to do a single memory allocation and store the reference counter and the object next to each other in memory. make_unique doesn't really have any benefits other than a more convenient syntax.

[Cubbi]

I think make_shared was added first because it allows it to do a single memory allocation

right, make_shared/allocate_shared require access to implementation detail and so have to be provided by the library. They were introduced (under slightly different names) to standard C++ via http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1851.pdf (2005) and implemented (the way we know them) in boost in version 1.34 (2007). Some non-standard shared pointers had similar factory functions back before then, SharedPtr::createInPlace and whatnot.

The unique_ptr appeared earlier in 2005, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1771.html and make_unique was seen as trivial, but it was only trivial to the committee members, so it was was introduced via http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3588.txt (2013)

[homing]

well ok thank you :)

[homing]

hmm, somewhere I heared, sometimes 'new' might be used in low level or library code..
what do you guys think?

[Moschops]

That is correct. Sometimes, 'new' might be used in low level or library code. It also sometimes might be used in high level code.

[homing]

But when ? :o

[JLBorges]

> But when?

When we need to implement low-level infrastructure components.

For instance, http://www.cplusplus.com/forum/beginner/154004/#msg796734

Or we want to implement a user-defined allocator.

[homing]

hmm ok.
As far as i know, new is still used in the STL.
On the cppcon Herb Sutter from the C++ ISO said the they could remove new and use smart pointers with >nearly< no overhead.

[JLBorges]

new will never be removed from the standard.

Removing new would:
Break almost all existing well-formed code.
Remove the facility for placement of objects with placement new
...

std::unique_ptr<> with std::default_delete<> as the deleter has zero or near-zero overhead over a raw pointer. Other standard smart pointers have measurable run-time overheads.

[homing]

ofc not remove. he just gave a example about performance, that they could use smartpoints instead of raw pointers, with nearly no overhead.