DIP60: @nogc attribute

Michel Fortin via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 16 17:06:30 PDT 2014


On 2014-04-16 23:20:07 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 4/16/2014 3:42 PM, Adam Wilson wrote:
>> ARC may in fact be the most advantageous for a specific use case, but 
>> that in no
>> way means that all use cases will see a performance improvement, and in all
>> likelihood, may see a decrease in performance.
> 
> Right on. Pervasive ARC is very costly, meaning that one will have to 
> define alongside it all kinds of schemes to mitigate those costs, all 
> of which are expensive for the programmer to get right.

It's not just ARC. As far as I know, most GC algorithms require some 
action to be taken when changing the value of a pointer. If you're 
seeing this as unnecessary bloat, then there's not much hope in a 
better GC for D either.

But beyond that I wonder if @nogc won't entrench that stance even more. 
Here's the question: is assigning to a pointer allowed in a @nogc 
function? Of course it's allowed! Assigning to a pointer does not 
involve the GC in its current implementation... but what if another GC 
implementation to be used later needs something to be done every time a 
pointer is modified, is this "something to be done" allowed in a @nogc 
function?

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca



More information about the Digitalmars-d mailing list