Is that really proper use of the term garbage collection? If you are doing memory management manually, it sounds more like the lack of garbage collection. Unless they were using an unsafe GC for C/C++?
I've never done this kind of programming around GC, is manual memory management in a garbage collected language any better than manual memory management in a language without GC?
>I'm not so sure there are applications which simply cannot tolerate garbage collection.
From your post, it sounds like "tolerating garbage collection" is the same as making sure it never ever happens. The application clearly doesn't tolerate GC, the programmer tolerates the language enough to bend over backwards to avoid one of its central features.
Am I misunderstanding something or does the author seem to be conflating garbage collection with the automatic memory management C++ enables via smart pointers? Those are two entirely different things.
You typically use a weak pointer from child to parent in those situations. So there are no ownership cycles. Languages without garbage collectors (C/C++) pretty much require you to not have ownership cycles or your code will crash during cleanup. Unless you add specific code to detect it and stop it from happening. So I assume you mostly work in GC languages and not C/C++?
I'm not sure you can actually call this garbage collection. It seems like manual memory management to me. Javascript actually has a GC but this seems like it's trying to ride off the novelty of the idea of implementing a GC in a language that already has a GC... but I'm not convinced that is what is actually happening.
If you'd like to call that a form of GC, I'd prefer to call it "compile-time GC" to avoid confusion. I rarely see "garbage collection" being used to refer to anything other than dynamic garbage collection.
You can also integrate unsafe manual memory management with a full garbage collector in environments like .NET. Use the GC for 99% of your code, manually malloc/free/pin the other 1%.
It seems a bit odd to complain that C++ doesn't support garbage collection. I mean yes, it's true, but... part of the point of C++ is to give you control of memory.
I never understood the need for Garbage Collectors.
In my opinion, the difficulties of memory management are extremely overrated. I write code in C/C++ for almost 20 years and I never encountered a difficult bug that would have been avoided with a Garbage Collector.
If a coder really has a hard time with manual memory management it means he can't really code, this is a beginner problem...
There's no code to hint at how garbage collection should be done, since its automatic. You have to essentially include a library that would emulate the source language gc that it came from so its not a direct translation from one language to another. At least that's what I was thinking
I'm a C++ programmer who hates garbage collection on general principle, but I have to say: 20% of CPU time spent in memory management isn't all that unusual (especially in software that hasn't been optimized), whether or not that memory management is automatic garbage collection or manual.
>Nonsense. Most languages that include garbage collection allow you to turn it off; the same languages also allow you to explicitly control memory.
BS. Most languages don't allow you to turn off their GC, except if by it you mean doing silly tricks and jumping through hoops, using tons of memory to avoid having to GC, using pools of pre-allocated objects, not using any standard libs, etc. Even then, they are not callable from outside code (like C is and Rust tried to be) and memory use is huge.
reply