Newbie initial comments on D language - scope

Walter Bright newshound1 at digitalmars.com
Tue Feb 5 23:34:28 PST 2008


Edward Diener wrote:
>> It will be required as any user could declare an object instance as 
>> 'scope', and so any separately compiled code must anticipate that.
> I agree in the sense that every object may need to carry an extra 
> reference count with it even though it will not be used for the vast 
> majority of objects, which will be GC. I do not view this as an issue.

It's a very serious issue, as it essentially negates much of the 
advantage of general gc. For one example, you'll have to give up 
interior pointers.

>> It's just that if any object could be scoped based on a runtime test, 
>> that then you've got to insert that test at every assignment, copy 
>> construction, and scope exit. You've got all the overhead of RC.
> Yes, agreed. There will be overhead to deal with 'scope' objects. 

It will be needed for *every* gc object, too. And not just the 
allocation for the reference count, the test has to be executed every time.

> However you already have some overhead dealing with stack variables, and 
> so has C++ for its existence at the end of each scope and it sure does 
> not make C++ slower than most GC systems.

If reference counting worked that well, there would be no push to add gc 
to C++0x.


> I can not say too strongly that if RAII, via 'scope', is to work in D or 
> any other GC language, the end-user should be as oblivious as possible 
> to it working automatically. This means that class designer, who surely 
> must know whether objects of their class need RAII, tells the compiler 
> that his type is 'scope' and the end-user proceeds to use objects of 
> that type just as if he would use normal GC objects.
> 
> Otherwise you are creating a bifurcated system which does the end-user 
> no good. Not only must the end user know something in advance about the 
> inner workings of a class ( that it needs RAII ) when the class designer 
> already knows it, but he must also use a separate notation to deal with 
> objects of that class.

For those cases, all the class designer needs to do is present to the 
user the struct wrapper for the class, not the class itself.


>> Then you have the problem that all generated code that manipulates any 
>> object must insert all the rc machinery for that object, just in case 
>> some user somewhere instantiates it as 'scope'.
> 
> It needs to have inserted for it the mechanism which determines whether 
> that object is a 'scope' object or not. It probably needs the extra int 
> for possible reference counting. Other than that I do not see what other 
> machinery is needed for normal GC objects.

Consider:

void foo(C c) { C d = c; }

foo() has no idea if c is ref counted or gc. Therefore, it has to check 
every time, at run time. All the machinery has to be there, just in case.

> If we are really still in the age, with vtables and alignment padding 
> and god knows what else a compiler writer needs per object to correctly 
> do his work, where another 4 bytes of int is considered prohibitory, 
> then I give up the whole idea <g>.

It's not just another 4 bytes.



More information about the Digitalmars-d mailing list