On Mon, 18 Aug 2014 10:01:57 +0000 maik klein via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> First of all I don't want to insult anyone on language design, I > just want to know the reason behind the "always on" GC. > I know that the GC as several advantages over reference counting, > especially when it comes to immutable data structures. > What I don't (correct me if i am wrong) understand is why every > heap allocation has to be garbage collected, like classes, > dynamic arrays etc. > Does a GC still have advantages over heap allocations that do not > need to be reference counted such as the unique_ptr in c++? > The dlang homepage stats: > > Destructors are used to deallocate resources acquired by an > object. For most classes, this resource is allocated memory. With > garbage collection, most destructors then become empty and can be > discarded entirely. > > If I understand it correctly it means that D has a GC, so most > classes don't need a destructor anymore because they don't need > to do any cleanup. I am not totally convinced that this would be > a good trade off in general. Maybe someone could shine some light > on this statement? The biggest reason is memory safety. With a GC, it's possible to make compiler guarantees about memory safety, whereas with manual memory management, it isn't. It's also pretty hard to do stuff like automatic closures and delegates without a GC, and the behavior of D's dynamic arrays - particularly with regards to slices - is much harder to do without a GC. The result is that there are a number of features which you lose out on if you don't have D's GC (though they're not features a language like C++ has, since it doesn't have a GC). However, it's also not true that the GC is necessarily always on. You can disable it. It's just that you do so, you lose out on certain language features, and memory management becomes a bit harder (particularly when it comes to constructing classes in malloced memory, but the custom allocators which are in the works should fix that). However, with the way a typical D program works, a lot more goes on the stack than happens with a typical GC language, so the fact that it has a GC wouldn't be as big an impediment as it is with some other languages, if you couldn't turn it off. So, having the GC gives us a number of features that aren't really possible without it, and unlike languages like Java, you _can_ turn it off if you want to, though you do lose out on some features when you do. So, ultimately, about all we really lose out on by having the GC is having folks who want a systems language freaking out about the fact that D has a GC and frequently assume that that means that they have to it and that D is not performant. - Jonathan M Davis