GC'd C++

I've heard rumors of a GC'd C++. Is it possible, and what are the implications? Wouldn't it just have to end up being an (compiled) interpreter that gets embedded into the executable at runtime?

I mean, you have some people saying things like:

"Garbage collection can be easily implemented with smart pointers (objects that wrap pointers with a reference count, which auto delete themselves when the reference count reaches 0)."

No, that's not GC. Thats reference counting. It doesn't handle cyclical data structures.

If you're compiling to straight ASM, I don't see how you can get GC at that level, without implementing another level on top to keep track of the root sets. And if you're implementing another level on top, you're not in straight ASM anymore..

Hmm, what if someone can implement GC at the hardware level..?

A similar train of thought:

"The idea behind C++ was that you would not pay any performance impact for features that you don't use. So adding garbage collection would have meant having some programs run straight on the hardware the way C does and some within some sort of runtime virtual machine."

"I don't think GC requires a VM. The compiler could add code to all pointer operations to update a global state, while a separate thread runs in the background deleting objects as needed."

"I agree. You don't need a virtual machine, but the second you start having something manage your memory for you like that in the background, my feel is that you've left the actual "electric wires" and have sort of a VM situation."

One last idea: the hardware stack is "automagically" GC'd, and C++ "smart pointers" take advantage of this using their destructors and reference counting to release resources when the _pointers_ are popped off the stack. However, if one wants (to *implement*) a purely heap-based approach (such as is required for some aspects of a functional language interpreter, like Scheme), then we can't use that paradigm anymore (since no stack is used). Now what do we do?

Alright one last thing... at the hardware level, the "stack" isn't any different than the "heap", except that the stack has a fixed limit and is always used in a LIFO (last-in-first-out) fashion. RAM is RAM, a fixed constant number. The stack is just some (usually small) area set aside especially to be used only in that fashion.

Quote:

---

Originally Posted by MacNilly

No, that's not GC. Thats reference counting. It doesn't handle cyclical data structures.

---

What's the difference? Why can't it handle cyclical data structures?

Because, say 2 objects A and B, A contains a reference to B, and B contains a reference to A, their reference count is 1 for each of A and B, always. Even if no other object C has a reference to it. It's just garbage.

I'll admit, it's probably a corner-case. But a simple smart-pointers implementation won't handle that. In order to handle that, you need to know all references, A, B, C, ... Z

Well, yes of course that would be a limitation. Another approach to avoid this problem would be to replace the reference count with a reference list, that way we could scan for objects that only reference themselves or references( referents? referees? ) that only reference them. That of course comes with the huge disadvantage that every time a "drop()" gets called, the thread drops everything else and tries to figure out whether to delete that object or block of objects.

It's ... complicated.

Well, there is garbage collector support. If you scroll down on this page you can see a section about garbage collector support.

The thing is though, C++ doesn't need a garbage collector, by and large. I think cyclical structures are partially handled by `weak_ptr` and if not that then I think the idea of a "deferred_ptr" is floating around somewhere. Graphs and lifetime management can be quite tricky. Otherwise, normal RAII mechanisms are largely sufficient.

Thanks for the replies. I really only care because I'd like to port a Java project into C++, and I'm concerned about how to manage memory usage. The project is a simple interpreter for a functional language that I'd like to use a heap-only allocation strategy for, and there's no way to decide when to call "delete" for the many calls to "new" that will occur for temporaries, etc.

No, C++ itself may not need GC, but if one is using C++ to implement the a language that requires it, then either I have to implement my own GC layer on top of C++, or find a library that will GC my whole project.

I would like to just re-write malloc() or overload operator new, but given the structure of the interpreter, there aren't any good place to do deletes.

Python and Lua are both implemented in C, and claim to have GC, so perhaps I'll delve into that convoluted source code and see how they did it.

Quote:

---

Originally Posted by MacNilly

...port a Java project into C++, and I'm concerned about how to manage memory usage.

---

RAII. If it weren't for the fact that everything is forced to be a reference in Java, most things could live on the stack, and not require a call to new. Use that philosophy when porting, and it should improve your state of affairs considerably.

Link to high level overview of RAII RAII - cppreference.com

Tim S.