Go, D, and the GC

Dmitry Olshansky via Digitalmars-d digitalmars-d at puremagic.com
Mon Oct 5 00:01:00 PDT 2015


On 05-Oct-2015 09:52, Shachar Shemesh wrote:
> On 04/10/15 19:14, welkam wrote:
>> On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote:
>>> these tools are not very good and they don't help when the standard
>>> library(...or builtin language features...) use the GC and tie your
>>> hands
>>
>> IMO tools for memory management in D are way better than that of other
>> languages. Game developers who use c++ dont use all of c++
>> features(templates, exceptions), because they care about performance the
>> same can be said about D. Yes some features use GC heap, but you can
>> just not use it. Or you can use so little that GC collection wont even
>> kick in. With Go you have no real option but to use GC.
>
> When D structs has a destructor that is guaranteed to run for any
> instance that finished construction, no matter what is the use case,
> then we can have that discussion.
>

Supposed to be the case for structs except for any bugs.

> Until then, no, D's mechanisms for non-heap allocations are vastly
> inferior to C++'s.

Well need some helpers for RC/on stack classes plus kill that horrible 
extra monitor field.

Otherwise I fail to see how. Plus with D's everything is movable by 
default. I mean I can memcpy D's structs just fine _by spec_ provided 
that I bitblit T.init over the source.

In C++ you can't - not only self-references are permitted but also there 
is no T.init so there is no bit-pattern that is guaranteed to not 
explode in dtor.


> Shachar


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list