Why does D rely on a GC?

[Paulo Pinto via Digitalmars-d]

Am 18.08.2014 20:56, schrieb b:
>> A good reason is the ability to write lock-free algorithms, which are
>> very hard to implement without GC support. This is the main reason why
>> C++11 has a GC API and Herb Sutter will be discussing about GC in C++
>> at CppCon.
>
>   *some* lock free algorithms benefit from GC, there is still plenty you
> can do without GC, just look at TBB.

Sure, but you need to be a very good expert to pull them off.

>
>> Reference counting is only a win over GC with compiler support for
>> reducing increment/decrement operations via dataflow analysis.
>>
>> C++ programs with heavy use of unique_ptr/shared_ptr/weak_ptr are
>> slower than other languages with GC support, because those classes are
>> plain library types without compiler support. Of course, compiler
>> vendors can have blessed library types, but the standard does not
>> require it.
>
>   Not really accurate. First of all, don't include unique_ptr as if it
> had the same overhead as the other two, it doesn't.

Yes it does, when you do cascade destruction of large data structures.

>
>   With RC you pay a price during creation/deletion/sharing, but not
> while it is alive.
>   With GC you pay almost no cost during allocation/deletion, but a
> constant cost while it is alive. You allocate enough objects and the sum
> cost ant so small.
>
>   Besides that, in C++ it works like this.
>   90% of objects: value types, on stack or embedded into other objects
>   9% of objects: unique types, use unique_ptr, no overhead
>   ~1% of objects: shared, use shared_ptr/weak_ptr etc.

It is more than 1% I would say, because in many cases where you have an 
unique_ptr, you might need a shared_ptr instead, or go unsafe and give 
direct access to the underlying pointer.

For example, parameters and temporaries, where you can be sure no one 
else is using the pointer, but afterwards as a consequence of destructor 
invocation the data is gone.

>
>   With GC you give up deterministic behavior, which is *absolutely* not
> worth giving up for 1% of objects.

Being a GC enabled systems programming language does not forbid the 
presence of deterministic memory management support, for the use cases 
that really need it.


>
>   I think most people simply haven't worked in an environment that
> supports unique/linear types. So everyone assumes that you need a GC.
> Rust is showing that this is nonsense, as C++ has already done for
> people using C++11.
>

I know C++ pretty well (using it since 1993), like it a lot, but I also 
think we can get better than it.

Specially since I had the luck to get to know systems programming 
languages with GC like Modula-3 and Oberon(-2). The Oberon OS had quite
a few nice concepts that go way back to Mesa/Cedar at Xerox PARC.

Rust is also showing how complex a type system needs to be to handle all 
memory management cases. Not sure how many developers will jump into it.

For example, currently you can only concatenate strings if they are both 
heap allocated.

There are still some issues with operations that mix lifetimes being
sorted out.


--
Paulo