3 ms·
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 wi
by mjn 13y ago
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.
- steveklabnik 13y agoAbsolutely. 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.
- pcwalton 13y ago> 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.
- bdash 13y agoWebKit 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.
- pcwalton 13y agoYeah, 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.
- yuushi 13y agoIt 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.