[felipefar]

Hard pass on the garbage collector. We don't need that, and the minimal GC support that was in the standard has been removed from C++23.

[pizlonator]

> Hard pass on the garbage collector.

Why?

> We don't need that

You do if you want comprehensive use-after-free protection.

> and the minimal GC support that was in the standard has been removed from C++23.

Not related to what I'm doing. The support you cite is for users of the language to write garbage collectors "on top" of the language. Fil-C++'s garbage collector is hidden in the implementation's guts, "below" the language. Fil-C++ is compliant to C++ whether C++ says that GC is allowed or not.

[jandrewrogers]

Garbage collectors are directly in conflict the requirements of many high-performance software architectures. Some important types of optimization become ineffective. Also, GC overhead remains unacceptably high for many applications; performance-sensitive applications worry about context-switching overhead, and a GC is orders of magnitude worse than that.

C++ is usually used when people care about performance, and a GC interferes with that.

[felipefar]

They solve the use-after-free issue by keeping pointed objects alive, not by helping you think better about object lifetimes in your code. That means some objects will live for longer than you initially thought they would, and potentially even introduce circular references. Added to that, they also introduce random, unpredictable slowdowns in your application to run their algorithms.

I'm not yet sold on Rust, but exploring alternatives for achieving memory safety without needing to put on a GC is commendable.

[3836293648]

Because if you can afford GC you're not using C/++. We need memory safe systems stuff. Higher level memory safety has been solved for decades

[pjmlp]

Unreal C++, C++/CLI, and V8 C++ do need one.

It should never have been there in first place, because it ignored their requirements, and thus it was never adopted by them or anyone else.