a C++ experienced programmer, I spoke recently to, told me that using new and delete is basically prohibited nowadays in C++ in favour of std::make_unique, std::make_shared etc.

▲

bluGill 2 hours ago | parent | next [-]

For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance. That last 5% though you are doing weird things and so need to do something manually. (as the other poster said, make_unique is implemented with new) Of course the 5% is overall. Some projects never have anything that gets into that last 5%, while others it is more like 50% of the code can't use make_*. If at all possible your use of new/delete should be limited to a data structure/container than handles it, and not scatters all over.

▲

RossBencina 2 hours ago | parent | next [-]

"For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance."

For 95% of code std::unique_ptr has no loss of performance. Perhaps. Just remember that it is not a zero-cost abstraction, the compiler won't always be able to entirely eliminate the overhead:

https://www.youtube.com/watch?v=rHIkrotSwcc

	▲	bluGill 2 hours ago \| parent [-]
		I watched that about 7 years ago when it first came out, and at an hour long I'm not about to watch it again... From what I can recall those are things that rarely are important. There is a cost, but in most real world code they only add a few nanoseconds - I have more important things to worry about.

▲

smallstepforman 30 minutes ago | parent | prev [-]

The unique_ptr destructor is called on scope exit, and there are times you want this earlier before other critical code.

	▲	jmalicki a few seconds ago \| parent \| next [-]
		That's why you can define your own scope to control that.
	▲	bluGill 6 minutes ago \| parent \| prev [-]
		[dead]

▲

RossBencina 3 hours ago | parent | prev [-]

In many application code bases no doubt. But how do you think make_unique and make_shared are implemented?

▲

pjmlp 2 hours ago | parent [-]

With what will most likely become [[unsafe]] profile in C++29, assuming WG21 actually gets their profiles story right.

▲

bluGill 2 hours ago | parent [-]

I don't think adding unsafe will be possible - it will break too much existing code. We might be able to add something new that is only possible in an unsafe context, but there is too much existing code.

However I do expect a [[safe]] profile (or perhaps several, depending on which paper you read) that everyone is encourage to opt-in to. Likely combines with compiler warnings and static analysis to encourage that use. (Also syntax is still open for debate)

▲

pjmlp an hour ago | parent [-]

Check the WG21 mailing proposals.

I was for Safe C++ paper, based on Circle experience, but it was shot down due to politics.

So we're left with the profiles camp actually delivering, followed by the remaining compilers caring to actually implement them, otherwise it will be static and dynamic analysis as usual.

	▲	will4274 11 minutes ago \| parent [-]
		It wasn't shot down due to politics. It was shot down because it solved the wrong problem.