| > You are still creating objects, be they heap or stack based. You are still choosing data structures and designing systems that will have an impact on object lifetime. As you do in any language. > You are still worrying about taking references during captures of objects, and making sure it is the right type of reference, and that the object does eventually get released. Bonus points if this happens across threads (and with today's async programming models, it will happen across threads!) In the case of modern C++, Swift, even ObjC–by “you”, you mean the runtime? Following relatively simple rules does not create a huge cognitive burden on developers, I think. > And memory is still being fragmented, especially if the data model is complex. Agreed, but then, we are speaking here of desktop-class applications, and fragmentation issues should be very rare in this day and age. > In a GC language, that fragmentation goes away. Worrying about when an object is out of scope goes away. Capture as often as you want, toss objects between threads, no worries, it will get cleaned up eventually. There are pitfalls to avoid, accidentally keeping a reference around will leak memory, but that it true in C++ as well. GCs solve most of the issues. Modern C++ makes it better, but there is still a quantifiable ease of use difference between modern C++ and a GC'd language. There is also a quantifiable performance penalty to GC’d languages and defragmentation. And GC introduces a class of issues that are so subtle, only experienced developers with experience are able to properly debug or even know about. |
Most GC languages force the issue for you. Everything on the heap. That said, I'd love it if more GC'd languages were smart enough to know when they can stack alloc. :)
> Agreed, but then, we are speaking here of desktop-class applications, and fragmentation issues should be very rare in this day and age.
They become a problem with any long lived application that throws around large chunks of data. From video games to productivity apps. Soon as interactive runtimes become multi-hour, life gets harder.
> There is also a quantifiable performance penalty to GC’d languages and defragmentation.
Depends on usage. Destructor chains can take up large amounts of time as well, and from the programmer's POV, are about as deterministic as GC pauses. On the plus side, they typically only pause one thread instead of the entire world. :) (Not much help if it is the app's main thread, or UI thread, heh)
> And GC introduces a class of issues that are so subtle, only experienced developers with experience are able to properly debug or even know about.
And they also prevent a lot of those same issues. It is a trade off. But I'd say that for 90% of coding, the cognitive load from GC is lower than from using C++. A brand new C++ codebase written by people who are all strictly following the Right Way to do things will look good, but the majority of code is old. The majority of libraries being used were not written in accordance with the latest C++ spec, every single third party library doesn't use unique and shared pointers, leading to natural conflicts at interfaces between libraries.
Pick a mature (has libraries written in it) GC'd language and that all goes away.