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).

▲

p0w3n3d 2 hours ago | parent [-]

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 an hour 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 an hour ago | parent [-]

"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 35 minutes 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.

▲

RossBencina 2 hours ago | parent | prev [-]

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

▲

pjmlp 41 minutes ago | parent [-]

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

▲

bluGill 32 minutes 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 a minute 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.