Maybe D is right about GC after all !

[Jonathan M Davis]

On Tuesday, December 19, 2017 23:53:04 bachmeier via Digitalmars-d wrote:
> On Tuesday, 19 December 2017 at 13:14:50 UTC, Mark wrote:
> > On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright
> >
> > wrote:
> >> "C, Python, Go, and the Generalized Greenspun Law"
> >>
> >> http://esr.ibiblio.org/?p=7804
> >
> > What do you think of the following comment to that article?
> >
> > "In well-written modern C++, memory management errors are a
> > solved problem. You can just write code, and know that the
> > compiler and library will take care of cleaning up for you,
> > just like with a GC-based system, but with the added benefit
> > that it’s deterministic, and can handle non-memory resources
> > such as file handles and sockets too."
>
> I'm no C++ expert, but isn't that because of the use of unique
> pointers and shared pointers? And aren't shared pointers
> reference counted and stuck with the usual limitations associated
> with reference counting?

What limitations are you concerned about? Certainly, shared_ptr comes with
whatever pros and cons come from non-intrusive (i.e. not built into the
object) reference-counting, but from I've seen, there really isn't much of a
downside to them (_especially_ if you're comparing them to manual memory
management). Mostly, you just have to worry about using weak_ptr when you'd
otherwise have a circular reference. Sure, using the GC is easier but not by
much. In my experience, you can generally just use shared_ptr and not worry
much about memory management, and you get mostly deterministic destruction,
unlike the GC (it's mostly, because there are times when stuff sticks around
a lot longer than you might expect, because something has a reference to it,
which isn't always obvious; it's still technically determinstic, but the
effect can seem pretty non-deterministic sometimes). There are plenty of C++
programmers who have no problem with shared_ptr who would feel quite leery
about using the GC, and for some stuff, the determinism of reference
counting can be critical. With a GC, you can mostly not worry about such
things, but occasionally, you have to be careful, or you'll have problems
with resource management because on the non-determinism (e.g. you really
don't want sockets to closed based on when the GC collects the socket
object). And whether RC or GC is better for performance depends heavily on
what you're doing. RC tends to slow everything down slightly but usually
doesn't have bursts of memory collection (though it can when you free a
large tree of objects at once), whereas the GC doesn't slow stuff down as it
goes along, but it has definite bursts where performance tanks, because a
collection is being run. I'd say that from D's perspective, the main
advantage of the GC over RC is that the compiler can guarantee that it's
@safe, which is more more problematic with RC - that and you don't have to
worry about circular references with the GC like you do with RC.

Overally, I don't think that it's particularly clearcut whether RC or GC is
better overall. The big thing is that the memory is managed automatically
rather than manually.

- Jonathan M Davis