Nice article. There a few issues with your code however from a cursory glance; your dtor seems to allow for spurious/double frees due to custom deleter support (you wanna check up on that), you also seem to use seq_cst far too much even if not needed (you want to avoid them is queues as much as possible), lastly class FastQueueNodeSlot.. isn't aligned (plus 64b alignment is only a thing for amd64 cpus, apple silicon is larger).
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.
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.
"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
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.
As a firmware developer commonly operating on devices with 32MHz of cpu, i am offended sir.
If your doing firmware you probably shouldn't be doing much memory allocation at runtime anyway to prevent memory fragmentation.
Even at 32Mhz you typically have more important things to worry about. These nanoseconds are unlikely to add up - the overhead from the underlying new/delete is going to be much worse.
The unique_ptr destructor is called on scope exit, and there are times you want this earlier before other critical code.
That's why you can define your own scope to control that.
you can call release or reset as needed if you want the delete to happen early - and if you forget an obscure code path it still gets deleted on scope exit which is probably good enough for that path.
In many application code bases no doubt. But how do you think make_unique and make_shared are implemented?
With what will most likely become [[unsafe]] profile in C++29, assuming WG21 actually gets their profiles story right.
Classic C++, any issue is at most three years away from going away! There will definitely not be any other issues that are also three years from getting fixed when you reach that year though
Actually no, because you are missing the time between standard being ratified and actuality being widely available in all major compilers.
By the way, it is also classical Web standards, C, Vulkan, OpenCL, and everything else that has a similar process.
Ideally we should have gotten rid of C and C++, but I haven't yet found a better Typescript for C.
Fair enough, three years might be more of an upper bound than a lower bound. And yeah, the issue of having to wait is common to standard-based processes, but I've never seen anything else based on a standard so frequently have people need to jump in and try to dissuade people that issues matter because of the rolling timeline so frequently, regularly, and for such a long time as C++. Obviously it would be unreasonable to expect it to become perfect and not need any more changes, but like, I was hearing people complain about various aspects of `unique_ptr` a decade ago, and it seems like we're not even past that yet.
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)
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.
It wasn't shot down due to politics. It was shot down because it solved the wrong problem.
Yeah, that is why there was a paper created specifically to kill any other proposal, by the profiles folks with WG21 majority, and ironically profiles are just as annotation heavy, but since it is profiles, it is alright.
I call that politics, and in the end the most likely outcome is that by C++29 nothing will be delivered by the profiles group, that is any better than using clang-tidy already today.