I like the idea. I have wondered why not have a "garbage collected" smart ptr std::gc_ptr<T> that can allow cycles with other such ptrs to avoid the short coming of std::shared_ptr<T>. You would need to define which gc_ptr's are in your "root set" to initiate the "mark and sweep" of the graph of ptrs. This would be useful for heavily linked data structures with cycles.
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
Comments
I like the idea. I have wondered why not have a "garbage collected" smart ptr std::gc_ptr<T> that can allow cycles with other such ptrs to avoid the short coming of std::shared_ptr<T>. You would need to define which gc_ptr's are in your "root set" to initiate the "mark and sweep" of the graph of ptrs. This would be useful for heavily linked data structures with cycles.
That is in Microsoft's managed C++ called C++/CLI that is compiled for the CLR. It uses the ^ (hat) sigil, i.e. "int^" vs "int*".
Yeah, don't do much MS programming anymore. I expected something like this in boost.
This is a sensible next step for C++. I would only "cost" you if you used it. And would come in very handy in some situations.
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