Aggregates & associations

[Steven Schveighoffer]

"Sean Kelly" wrote
> Steven Schveighoffer wrote:
>> "Sean Kelly" wrote
>>> A long time ago Walter mentioned that the "scope" attribute may be 
>>> extended to indicate aggregation:
>>>
>>>     class Foo
>>>     {
>>>         Bar valA;
>>>         scope Baz val2;
>>>     }
>>>
>>> With the above, the size of Foo would be expanded to contain an instance 
>>> of Baz and val2 would be initialized to reference this memory, very much 
>>> like "scope" works in functions now.  But I didn't see any mention of 
>>> this in the D 2.0 writeup so the idea may have been either discarded or 
>>> forgotten.
>>
>> I believe this type of behavior is not necessary.  Whether a member is an 
>> aggregate or an association, it will be deleted when nothing references 
>> it anymore, which is when it should be deleted.  The only thing this 
>> proposed behavior can do is cause segfaults when something that still has 
>> a reference to a scoped member tries to use it.
>
> You're right that it's not necessary.  The GC is supposed to take care of 
> this for you.  But constructing complex aggregates can be quite expensive 
> in terms of GC use, as a separate allocation must be made for every 
> object.  This can also reduce locality of the objects are of different 
> sizes, which may affect performance by incurring cache misses. Now, it is 
> possible in D 2.0 to get the size of an object and reserve space for it 
> using a static array, but this requires the use of placement new, which 
> requires yet more fancy template code to bolt onto existing classes, etc. 
> So this is certainly possible, but far messier than in C++.  And it's 
> really a fairly common design requirement.

I didn't quite understand your original post, thanks for explaining it 
further.

-Steve