GC vs. Manual Memory Management Real World Comparison

Felix Hufnagel suicide at xited.de
Wed Sep 12 13:38:53 PDT 2012


class Foo
{
     @safe nothrow:
	void method_is_nothrow(){}
	void method_is_also_nothrow(){}
}


or

class Foo
{
     @safe nothrow
     {	
	void method_is_nothrow(){}
	void method_is_also_nothrow(){}
     }
}

no need to append it to every single method by hand...



Am 12.09.2012, 04:38 Uhr, schrieb SomeDude <lovelydear at mailmetrash.com>:

> 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.


-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/


More information about the Digitalmars-d-announce mailing list