Newbie initial comments on D language - scope

[Edward Diener]

Janice Caron wrote:
> On 05/02/2008, Michel Fortin <michel.fortin at michelf.com> wrote:
>> Basically, you need to:
>>
>> 1. Load the object's pointer in a register
>> 2. Load the "scope" flag from memory by offseting the object's pointer
>> 3. Branch depending on that flag:
>>    a. if not scope, go to 4.
>>    b. if scope, do whatever is needed to increment the reference count
>> atomically, then go to 4
>> 4. Write the pointer to its new location.
> 
> Not quite. Consider an assignment
> 
>     A a;
>     B b;
>     a = b;
> 
> If I may be so bold as to rewrite this in C++, for clarity, that would
> look like:
> 
>     A* pa;
>     B* pb;
>     pa = pb;
> 
> That's the situation currently. Assignment of classes is very fast.
> /But/, this is what it would change to under your scheme:
> 
>     A* pa;
>     B* pb;
>     if (pa->refCount)
>     {
>         if (pb->refCount)
>         {
>             atomic { if (--pb->refCount == 0) delete pb; }
>             atomic { ++pa->refCount; }
>             pa = pb;
>         }
>         else
>         {
>             throw new RefCountException();
>         }
>     }
>     else
>     {
>         if (pb->refCount)
>         {
>              throw new RefCountException();
>         }
>         else
>         {
>             pa = pb;
>         }
>     }

pb being a 'scope' object does not matter and its reference count does 
not get adjusted downward just because its object reference is assigned 
to another object.

A reference counted 'scope' object means there is a single reference 
count ( probably somewhere out in Gc memory ) for all references to a 
particular object. When a new reference to that object is created, 
either through assignment, as above, or passing the object reference, 
the single reference count is incremented. So you can throw out a good 
deal of your imagined code above.

> 
> And that's just for /ordinary/ assignment. That looks like a
> phenomenal overhead to me. Now just /imagine/ how complicated it gets
> if you've overloaded opAssign in various complicated ways. (e.g
> structs assigned from classes, classes assigned from structs, etc.)
> 
> I think I'd rather not have that overhead added to every single class
> assignment.

You would no doubt claim that even if your code above were correct and 
much simpler. As soon as people are against an idea they find the 
necessary reasons to denigrate it based on such spurious thought. In 
computer programming the favorite claim for such thought is always the 
logic and supposed overhead of implementing anything.