auto, var, raii,scope, banana

[xs0]

Regan Heath wrote:
> On Wed, 26 Jul 2006 11:58:31 +0200, xs0 <xs0 at xs0.com> wrote:
>>> I like the use of scope at class decl. But, I prefer the no keyword 
>>> approach at instantiation. So, allow me to suggest this as a 3rd option.
>>>  - 'scope' at class decl.
>>> - no keyword at instatiation.
>>>  Reasoning:
>>>  'new' implies heap allocation to me. It would be beneficial to allow 
>>> the compiler to allocate an RAII type in any way it wants, perhaps 
>>> stack allocating it. Removing 'new' removes the implied heap 
>>> allocation allowing the compiler to allocate however it likes.
>>
>> Why would you want to deal with where the object is allocated?
> 
> My post _must_ have been missleading (more than one person thinks I want 
> stack allocation).
> 
> I don't want stack allocation. I was simply raising the possibility of 
> stack allocation as a possibly beneficial side-effect of removing 'new' 
> (which implies/required heap allocation, AFAICS)

'new' doesn't imply/require that heap allocation actually be done, it 
just requires the result to behave as if it was (look up "escape analysis")

>> Besides speed, is there any reason at all to allocate on the stack?
> 
> Speed isn't a good enough reason?

Speed is a good reason to use stack allocation. But that is also a good 
reason to let the compiler determine where to place an object, not the 
programmer.


>> If you always type the same thing, the compiler is always free to 
>> choose the best location. If you restrict "new" to allocating on the 
>> heap, you prevent the compiler from optimizing (by allocating on the 
>> stack) whenever it determines it's safe to do so (scoped variables are 
>> not the only such case).
> 
> Is it even possible for 'new' to allocate on the stack? I mean the stack 
> vanishes when the function exits, therefore isn't 'new' restricted to 
> the heap?

No. There are many cases where the object is not actually required to be 
on the heap.

>> Imho, "scope" is a perfect keyword for scoped variables/classes, for 
>> reasons already stated (already exists, good meaning, explicit). A 
>> missing "new" is not a good keyword ;)
> 
> I disagree, see my recent reply to "Chad J", specifically the scenarios 
> involving the C++ and Java programmers.

Well, I'm a Java programmer and if I see

A a = A();

I see a function call that returns something of type A. If I see

auto a = A();

I definitely see a function call. You'll never convince me that the lack 
of "new" is a good indication of anything, much less of the fact that 
it's a scoped variable.

> The only utility in static opCall is to emulate a constructor. Why not 
> replace them with a constructor (ie. rename "static opCall" to "this"). 
> Then, remove static opCall altogether.

Emulating a constructor is not the only utility, it's emulating an 
arbitrary function.


xs0