For some use cases that would matter, but for a lot of C++ use-cases, no GC isn't really fundamental. Large codebases increasingly use the "C++ GC", aka RAII with std::shared_ptr, as the de-facto-standard way of managing memory. For those kinds of applications, how D's GC compares then just becomes a matter of performance tradeoffs between different GC implementations, not a matter of GC vs. no-GC.

Absolutely. GCs have been improving a lot over recent years, and there's lots of software that's written in C++ that doesn't have to be.

You can write D without any GC at all, though: you lose a lot of the standard library at present, but I've done it. It's not possible, in my understanding, to turn the GC off in Go.

Set the env. var. `GOGC=off`.

D provides a little bit more control.

http://qznc.github.io/d-tut/memory.html

> Large codebases increasingly use the "C++ GC", aka RAII with std::shared_ptr, as the de-facto-standard way of managing memory.

Which large codebases? This is definitely not true for any of the browser engines (Gecko being the smallest at 6M LOC, and going up from there) for example.

WebKit makes relatively heavy use of reference counted objects, though a custom reference counting implementation is used rather than std::shared_ptr. That said, there has been an increasing emphasis on preferring unique ownership to shared ownership of objects where possible.

I'm a little confused by your throwaway comment about Gecko being the smallest browser engine though. WebKit weighs in at less than 3 million lines of code, much smaller than the size you quote for Gecko.

Yeah, I was thinking Chromium when I wrote that and should have been more specific. 6M is all of Firefox.

And Gecko uses reference counting a lot too, of course... but most objects are stack allocated or uniquely owned. It's a very different situation from a language in which all objects are reference counted.

It shouldn't be the standard way of managing memory; it should be a part of the toolkit. In order, it should look like:

1) Stack allocation 2) std::unique_ptr 3) std::shared_ptr

You should be properly thinking about onwership semantics, and unique_ptr should be the default, not shared_ptr.