GC vs. Manual Memory Management Real World Comparison
SomeDude
lovelydear at mailmetrash.com
Tue Sep 11 19:38:13 PDT 2012
On Tuesday, 11 September 2012 at 10:28:29 UTC, bearophile wrote:
> SomeDude:
>
>> It's a bad solution imho. Monitoring the druntime and hunting
>> every part that allocates until our codebase is correct like
>> Benjamen Thaut is a much better solution
>
> Why do you think such hunt is better than letting the compiler
> tell you what parts of your program have the side effects you
> want to avoid?
>
> Bye,
> bearophile
My problem is you litter your codebase with nogc everywhere. In
similar fashion, the nothrow keyword, for instance, has to be
appended just about everywhere and I find it very ugly on its
own. Basically, with this scheme, you have to annotate every
single method you write for each and every guarantee (nothrow,
nogc, nosideeffect, noshared, whatever you fancy) you want to
ensure. This doesn't scale well at all.
I would find it okay to use a @noalloc annotation as a shortcut
for a compiler switch or a an external tool to detect allocations
in some part of code (as a digression, I tend to think D
@annotations as compiler or tooling switches. One could imagine a
general scheme where one associates a @annotation with a
compiler/tool switch whose effect is limited to the annotated
scope).
I suppose the tool has to build the full call tree starting with
the @nogc method until it reaches the leaves or finds calls to
new or malloc; you would have to do that for every single @nogc
annotation, which could be very slow, unless you trust the
developer that indeed his code doesn't allocate, which means he
effectively needs to litter his codebase with nogc keywords.
More information about the Digitalmars-d-announce
mailing list