> With RAII popping stack frames means freeing resources recursively. If your free() implementation takes a lock then that can block other threads too, for an arbitrary time if the object graph being released is large.

For every RAII implementation I've seen, the recursive part is not within the free() implementation; the recursion happens outside the free() (or equivalent) calls, and free() (or equivalent) is called separately for each step, to release the memory for just that step. The time taken by each free() call is independent from the size of the object graph being released.

Not using GC. Not using reference counting. Not using "manual memory management".

And not contributing to the discussion.

At least bring some alternatives to the table or explain what you are doing and why you mean it's so much better..

When I developed programs in Fortran 77, I did indeed have zero pauses, because all memory was allocated statically at the program start. With any form of dynamic memory, you have effort for managing that dynamic memory and thus pauses. The different technologies only result in those pauses happening at different times and other consequences. Modern GCs at least allow most of the necessary computation to happen in a parallel thread.

> With RAII popping stack frames means freeing resources recursively.

Your "GC pause" simply happens on scope-exit.

Except, without the pause.

Oh, those cycles are free? That's not how I remember having to plan compute budgets and deadlines when I worked in real low-latency programming.

Erm something is managing your memory somewhere, even "the computer explodes before it runs out of memory" methodology used in guided missiles is a form of manual memory management, just a very unusual one.

Same applies to the "program terminates before it runs out of memory" approach.

Yes, something is managing my memory. Just not GC, and not reference counting (which is also GC). As I said.

C++ has destructors, and owning pointers (called "unique_ptr"), and also arena allocators for when those are useful. Rust has its Drop trait and analogs of the other things. (Use of arenas with Rust standard library containers is approaching maturity.) They make memory management automatic and wholly painless. Both languages offer reference-counted GC for places where that is helpful, but such places are rare, and where used typically burn an unmeasurably small fraction of runtime, with no "pauses".

Using destructors just reference counting done the hard way.

> burn an unmeasurably small fraction of runtime

That’s also known as a very short pause.

Yeah, right.

CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.”

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

Better making use of the best practices advised by Herb, otherwise those destructors are going to surprise you.

It'll surprise him anyway, eventually. After all--humans aren't perfect programmers.

It has been more than thirty years since a destructor surprised me. Herb was unlikely to have been programming at that time.

So what are your credentials in the C++ community to top those from Herb Sutter?

Been on ISO C++ Standard committee for much longer than Herb? But I have no disagreements with Herb.

And authored impactful C++ books and ISO C++ papers such as?

I have no need to "top" Herb. He says nothing inconsistent with anything I have said.

Apparently yes, when you place in doubt his advices,

> It has been more than thirty years since a destructor surprised me. Herb was unlikely to have been programming at that time.

So apparently you have skills that top one of the major C++ community figures.

Being so, the C++ community at large would appreciate those valuable insights.

The only conclusion one can draw is that you are wholly unable to comprehend what you have just read, or aggressively don't care what it says. Either way, enough is enough.