How did GC visibly fix their issues?

Manually managed code doesn't crash all the time. It probably crashed way more in the 90s. There is an art to writing manually managed code that is maintainable and fast, sure, and it doesn't involve malloc() and free(). And then there is RAII, automating lots of the work.

The C++ crazies are AFAICS still most everywhere where there is lots of temporary objects and serious requirements on throughput & latency. There are frameworks and languages that support garbage collection that get used in this space too, but I don't know how much can be inferred from that.

Seems like C and C++ guys are constantly looking for ways to automate their garbage cleanup.

And seems like GC guys are constantly looking for ways to fix their web-of-objects memory layout, and to prevent GC from ruining their performance. Plus, GC isn't deterministic, it mostly works for memory but otherwise you'll see _lots_ of manual cleanup code (not actually making use of the GC for this cleanup type code), and it always feels a bit tricky with the GC still being part of the game. Not that I take a huge issue with C-like cleanup code -- I think RAII can be tricky too because it's hard to "read" what happens. But compared to GC, at least RAII is deterministic.

The deterministic myth only works out for basic types, see Herb Stutter CppCon 2015 talk on the matter, and how performance workarounds turn out a poor man's GC.

That is a one and a half our long talk, can you point to the timestamp where he talks about determinism?

> and how performance workarounds turn out a poor man's GC.

If you need performance then it doesn't matter if it is a "poor mans GC", what matters is that it meets the space/time requirements, most general purpose GC tend to care about neither.

The only deterministic thing is the call point, Herb points out that just like calling malloc()/free() it is not possible to deterministically assert the execution time, more so with complex data structures where not only there is a domino effect of destructors being called, there is also the possibility of causing stack overflows if the destuctors are written incorrectly, to build an argument for presenting his deferred pointer class, which is basically a GC in disguise.

That is an obvious thing, and totally besides the point. Also, probably GC only helps little against this. Sure, actually calling the destructor can be delayed in order to even out latency. You can do the same with RAII.

Sometimes you can't do that though because you have certain constraints on the execution order of whatever routines you need to run. This is completely independent of whether you use manual cleanup or GC or RAII, however with GC it is weird/hard/impossible to synchronize the GC with the non-cleanup code.

I have anecdata to add to Herbs point.

I had a AAA project hitting 30ms pauses in free() implementation by platform vendor for quite popular gaming platform in 2016. Ofc it is anecdata but having actual deadlines from implementations is really hard. I had to replace malloc/free implementation like 3 month before ship date to avoid the issue.

free != destructor, that's the important point here.

What? RAII is totally deterministic, not sure what you want to contend here. CppCon 2015: Herb Sutter "Writing Good C++14... By Default": Not sure where I'm going to find my answer here.

Anyway, for complex state that must be cleaned up, maybe flushed before etc., you'll always find a lot of manual cleanup code, or otherwise find code with lots of random problems, often unreported. That is true both for GC languages as well as C++ and other languages with RAII or RAII-likes.

Unless you can static assert how long each destructor takes, it is not deterministic, even less if ownership is given to background threads for cleanup like on C++/WinRT.

The talk is "Leak-Freedom in C++", 2016 actually, https://youtu.be/JfmTagWcqoE?si=MY1JnWyybh5K8I8-

What I want to say here is the most basic thing. The order in which the destructors get called (also in the context of the other code) is deterministic. GC doesn't give you that. It should be obvious what I said.

Even that depends if constructors/destructors are ellided when UB or LTO are part of the picture.

An optimization that coroutines rely upon as means to remove the abstractions of their execution.

UB? What? That's completely off-topic. Please stop that, it's annoying.

I can't imagine what LTO should have to do with that either, but if there's any substance here please enlighten me.

The order in which destructors get called is well defined (and generally useful insofar as it's the reverse order of construction). Can't you just accept a simple argument? I'm not even a huge fan of RAII, but it has its uses.

There's some ambiguity for argument destruction order for example: https://stackoverflow.com/a/36992250

Similarly, the construction/destruction order for std::tuple elements is not well defined.

Granted, that's implementation defined behavior, which is technically deterministic on a single compiler.

This isn't really about constructors/destructors. Expressions like function calls with multiple arguments have always been "unsequenced" with respect to each other. In other words the order is left to decide for the compiler. It's always been like that, going back to C (and probably other languages). If you call f(x++, x++) what values get passed to f is unspecified.

I suppose the destruction of whatever the expressions constructed still happens in reverse order of construction.

But either way I might not even care, I'm aware that at the level of a single statement the execution sequences aren't much defined, so I rarely put more than one mutating thing per expression, or otherwise I'm sure that I don't care about the order -- I could live with any sequence as well as totally parallel execution.

Example: buf[i++] = 5 has 2 mutating sub-expressions, but I know it's not messing up anything. I don't care whether i gets incremented before 5 gets assigned or the other way around.

In modern C++, you no longer need to manually-manage your memory (except when writing custom containers and low-level libraries). Memory is managed automagically, no garbage is generated and no collection is necessary.

Of course, you can also do manual allocations if you really wanted to, but - with the changes in the language since C++11 - you just don't have the motivation to do it.

Yet C++/WinRT uses a background deletion thread to overcome pauses in cascade deletions of COM instances.

I wash my hands on any sort of MS Windows infrastructure...