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