GC vs. Manual Memory Management Real World Comparison

[Paulo Pinto]

On Wednesday, 12 September 2012 at 02:37:52 UTC, SomeDude wrote:
> 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.

This is partially what happens in C++/CLI and C++/CX.