Jump to content
  • Advertisement
Sign in to follow this  
wcassella

Practicality of a C++ Garbage collector

This topic is 987 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I love the idea of memory ownership, but I dislike how (in C/C++ at least) it breaks abstraction in the sense that you have to constantly be mindful of where things came from, and where they're going (not to mention how it just greatly complicates the language). While it doesn't feel out of place at a low level, if you never leave C++ it feels like you never actually escape it, even at the highest levels. There's Rust, which ingrains these things deeply enough that the compiler can catch errors for you, but I'm ruling it out until it's more mature.

 

The other side of the spectrum is Garbage collection, which I guess you could call "memory communism". There are third-party garbage collectors available for C++ (such as Hans-Boehm), but I was wondering if anyone here can provide anecdotes on using them in the real world. Should it be seen as a last resort? Can I depend on it entirely, even to the extent of making my collection classes use garbage-collected buffers?

 

Thanks

Share this post


Link to post
Share on other sites
Advertisement
I agree with Alberth. I exclusively use C# (garbage collecting runtime) and it's still extremely important to use a clean object/data ownership scheme. Edited by Nypyren

Share this post


Link to post
Share on other sites
Keep in mind that GC is generally only helpful for _memory_ resources. C++'s ownership model works for _all_ resources (memory, file handles, locks, internal state, etc.)

Share this post


Link to post
Share on other sites
All in all, I think C++ got it exactly right here (C++ got a lot of stuff wrong, but the ownership model maps very well to the nature of most situations, and as stated before it's universal, not just for memory). Your statement of C++ requiring you to be mindful at all times is a good argument against garbage collection, by the way. If a language forces the programmer to carefully think about what's going on (and either does not allow, or harshly punishes failure to comply), that is a big plus. Garbage collection can be useful (I consider smart pointers a form of garbage collection, by the way!), but while having "someone else" care is surely more comfortable, it is not inherently better. In fact, it can seduce you into writing vastly inferior code (not necessarily, but it can). Your designated usage is an example of that.

Collection classes use garbage-collected buffers
The question is: Why would you want to use garbage collection to manage buffers used by collections (or containers, as they're termed in C++)? The only way to add or remove objects from that pool of objects is via the API provided by the container class. It is therefore exactly known at all times whether an object is valid or not, and when it is to be destroyed. The container can just do that (and can in most cases reuse/retain the memory at no extra cost), there is not need for garbage collection. There is no way you could remove an element without the container class knowing. Also, the word "buffer" suggests that you do not plan to allocate and aggregate single elements (such as in a typical list), but rather manage a whole large buffer containing many small objects (such as e.g. in a vector). That's an even more compelling case against garbage collection. The container, and the container alone, knows exactly when a buffer has reached the end of its life (e.g. when a vector is resized, or when all elements are removed). Why should it leak that buffer and rely on some garbage collector to (maybe, eventually) pick it up? You spend extra CPU time doing that garbage collection, and meanwhile you keep more memory allocated than necessary. That's lose-lose, not win-win.

Share this post


Link to post
Share on other sites
In game development (or other high performance computing) understanding memory ownership is crucial to writing efficient code.

For most other tasks, it simply gets in the way, and worse, forces you to think in the language domain instead of the problem domain.

But that's why we have different languages. ):

Share this post


Link to post
Share on other sites


So far, I have not found a use for std::unique_ptr, although I am sure there exist valid use cases.

 

I think one of the best things about std::unique_ptr is that it is not copyable.

This helps enforce the ownership you define at compile time, which makes it harder to make mistakes. (it even catches when you by mistake try to make a copy of your vector of pointers)

 

As SmkViper says, it should be the default pointer type used, with the express meaning "this is the owner of the object"

 

Second best thing is that always using std::unique_ptr to define ownership means you never have to write "delete" again, which also means you can use the default destructor more often, meaning less code to write. (and the code you don't have to write, never has errors)

Edited by Olof Hedman

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!