Doesnt std::shared_ptr use garbage collection?
Most commonly though, "garbage collection" refers to global schemes which apply by default to all memory (perhaps with rare exceptions such as pinning).
So, in typical usage, C++ smart pointers, being opt-in, are not considered garbage collection. Languages which do automatic reference counting globally, such as Python or Swift, are indeed considered garbage collection schemes.
This is something I always thought was true, but then I see people talk about reference counting VERSUS garbage collection, when I was taught that reference counting is a subset of garbage collection.
In other words, "garbage collection" merely refers to any method of automatic memory management that the programmer doesn't have to think about, and reference counting is merely one method of implementing garbage collecting.
Heck, Python uses reference counting, yet the library for directly interacting with the reference counter is called "gc", for "garbage collection".
As I said, I think in practice any form of memory management that the language runtime/compiler does for you is considered garbage collection in the colloquial sense, but any such system where you have to use a specific language construct (such as std::shared_ptr or Rc) are not.
I'd also note that Python doesn't just do reference counting: it also has a tracing garbage collector that collects unreachable reference cycles. I'm not sure if Swift does something similar.
See also Herb Sutter [1] (describing a different project, but also mentioning shared_ptr):
> Q: "Is this garbage collection?"
> Of course, and remember that so is reference counting (e.g., shared_ptr).
[1] https://github.com/hsutter/gcpp#q-is-this-garbage-collection
I've seen people claim malloc and free are GC. And sure, you can get there, but it makes the term utterly meaningless.
Apparently you aren't even aware there are Lisp and Java implementations with reference counting algorithms for garbage collection.
1. That's a pretty ungenerous interpretation of "as seen in".
2. Are people expected to know about those specific implementations or they're a bad programmer? If that's your intent then screw off.
Also that sounds like a broken way to do "Java" without qualifiers. For Lisp, eh, you can even use a bump allocator if you want but that doesn't mean everyone should consider it every time they talk about Lisp.
And again, "as seen in [language]" doesn't mean that's the only way to implement it. If I talk about global locking "as seen in python" it doesn't mean I'm unaware of non-GIL python implementations.
If you are aware of non-GIL Python, you would say "as seen in CPython", otherwise it just proves the point of not being able to distiguish between implementations and language definitions.