D newb

[JAnderson]

Steven Schveighoffer wrote:
> "JAnderson" wrote
>> bearophile wrote:
>>> Joel Anderson:
>>>>> bearophile:
>>>>>> My question: does the compiler raise a compilation error if the 
>>>>>> 'scope' keyword is used where the compiler can't actually allocate the 
>>>>>> class on the stack? (if not, then I think it may be better for the 
>>>>>> compiler to raise such error, avoiding the illusion of efficiency).
>>>> If the class has a component sub-class the component may be heap 
>>>> allocated.  I don't agree with making that an error though.
>>> May I ask you why you don't like that as an error?
>>> Generally I don't like undefined situations, if I add the 'scope' keyword 
>>> I want the class to be stack-allocated, and I assume the compiler does 
>>> that. Then the layout of the memory used by the code is different, and I 
>>> can for example take care to avoid a stack overflow. If the compiler at 
>>> compile time is able to tell me that the class can't be allocated on the 
>>> stack, then I think the program has to not compile until I remove the 
>>> 'scope' keyword there. This makes the code reflect what the program 
>>> actually does.
>>>
>>> Bye,
>>> bearophile
>> What I'm talking about is:
>>
>> class A
>> {
>>
>>
>> }
>>
>> class B
>> {
>> ...
>> A a = new A(); // Heap Allocated
>> ...
>> };
>>
>>
>> ...
>>
>> scope B b = new B; //B is scope allocated but A is not
>>
>> Say your using someone else's class.  You get latest and you using one of 
>> there classes with the word scope.  They've decided to add something that 
>> is heap allocated.  Now suddenly your code is not working because someone 
>> made a slight change to their interface.
>>
> 
> The compiler cannot know when a constructor will decide to heap-allocate. 
> So it cannot predict whether the entire class will be stack-allocated.  Once 
> the constructor is called, you cannot extend the previous stack frame 
> (without a lot of extra work), and even then, it cannot be sure that the 
> calling function won't use that stack space later in the function.  I think 
> what you ask for is impossible to implement, and impossible to detect.
> 
> -Steve 
> 

I agree, however it could know weather members are likely to be heap 
allocated or not.  However I don't think that should raise errors.

-Joel