sgcl VS gcpp

The SGCL repository contains the source code for this benchmark that uses the tracked pointers: https://github.com/pebal/sgcl/blob/main/examples/treap/treap...

You can look at the SGCL garbage collector for C++: https://github.com/pebal/sgcl. It works in a separate thread, is locks-free and never stops the world.

It will never be called gc_ptr because C++ programmers have an allergy to the term GC. However, an attempt was made to implement a similar solution. Take a look at tracked_ptr: https://github.com/pebal/sgcl

SGCL is a real-time garbage collector for C++ without any pauses.

https://github.com/pebal/sgcl

Removed GC support was useless. You can have GC pointers in C++.

Mutators are threads that allocate memory and manipulate pointers, they can work completely independently of the GC. A mutator needs only to tag an object when copies or moves a pointer to this object. The GC detects this tag and marks the object as alive. Here is a working implementation for C++: https://github.com/pebal/sgcl

I don't know Rust but you can have a pauseless GC in C++. You just need to provide asynchronous access to root pointers.

static reflection and pattern-matching, as everyone is saying, but I'd also like to see a garbage-collecting smart-pointer in the standard library similar in design to Herb Sutter's deferred_ptr

There are definitely fringe edge cases where C++ can do things that Rust simply cannot, currently.

I'm thinking of things like Herb Sutter's deferred_heap (https://github.com/hsutter/gcpp) that give you GC-like abstraction. It's pretty cool that this is possible to write in vanilla C++ with decent ergonomics. I tried to make something similar awhile back and hit a wall in terms of making something that would be pleasant to use.

Rust has several on-going experiments with making a nice GC, along with good support for arenas. (If you can use arenas, they're great.)

Check out this library: https://github.com/hsutter/gcpp

Hm, yeah, that's pretty unclear. My understanding is based off the link to Herb's proposal in the OP, which I understand this to be an evolution of.

Re garbage collection: My understanding was that the standard API was intended for interop with managed languages, not for pure C++ code to use, although I could be mistaken. I don't think garbage collection is entirely a lost cause, for instance Herb Sutter's work, which I think he wants to integrate in Cppfront, would be a great way to do it. Imo, his garbage collection ([1] [2]) could be much better than D or Nim, because it has easily controllable performance characteristics. You don't pay for it if you won't use it, and it's unlikely that libraries you pull in would need it, which is imo what makes programming without the "optional" GC in D and Nim difficult.

Herb Sutter

Something like gcpp would be quite nice. That and a intelligent scope detector could make use of isolated and local GC when it detects that some objects stays together and have similar lifetime.