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