Newbie initial comments on D language - scope

Edward Diener eddielee_no_spam_here at tropicsoft.com
Sat Feb 2 13:18:06 PST 2008


Walter Bright wrote:
> Edward Diener wrote:
>> The idea in my mind is essentially that 'scope' classes automatically 
>> define an object that, when used exactly as an normal GC object, 
>> automatically calls the destructor of the object just as soon as the 
>> last reference to it goes out of scope. In this sense the user neither 
>> know or cares whether the object encapsulates a resource or not and 
>> uses an object of such a class just as he would use any other GC 
>> object. Similarly the user can force an object to be a 'scope' object 
>> through the second syntax give above, but from then on he treats the 
>> object just as he would any other GC object.
> 
> The problem is:
>     scope C c;
>     C d;
>     d = c;
> and now d is no longer properly ref-counted. The 'scopeness' of an 
> object must therefore be part of its type. The assignment d=c would have 
> to be illegal.

If C is a scope class, then it is fine and the normal reference counting 
occurs when d=c; occurs, n'est-ce pas ? If is not a scope class, then the

C d;

say that d is not a scoped object so that when:

d = c;

all that happens is that the reference count is not updated for this 
assignment and d going out of scope does nothing. In this latter case it 
is the responsibility of the end user, since he is scoping at the object 
level, to do the correct thing for whatever he wants.

IMO the 'scope' at the compiler level is part of the object, with the 
only difference being that objects of a 'scope' type are automatically 
'scope' without the user of the object specifying it.

If you want the lesser benefit of 'scope' being only part of the type, 
then you take away from the end user the ability to create a 'scope' 
object of a type which is not 'scope'. This may be easier for you, the 
compiler writer, but it means that containers of objects, which may hold 
objects of 'scope' type but are not 'scope' type themselves, do not get 
the benefit of reference counted deterministic destruction.

> 
> 
>> Please take a look at atomic operations, which I am sure you already 
>> know about. I believe boost::shared_ptr<T> in its latest incarnation 
>> is  using it to increment and decrement the reference count without 
>> the usual time penalty which you mention.
> 
> There has been a lot of work done improving atomic operations. That's 
> one reason for making it a library feature - the library stuff can be 
> improved without having to change the compiler.

As long as it is transparent to the end user you should do it in 
whatever the best way you deem possible.



More information about the Digitalmars-d mailing list