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