auto, var, raii,scope, banana

Regan Heath regan at netwin.co.nz
Wed Jul 26 03:41:21 PDT 2006


On Wed, 26 Jul 2006 11:58:31 +0200, xs0 <xs0 at xs0.com> wrote:
>> I say lets keep 'auto' for auto type inference (for the reasons you and  
>> Don mention)
>
> agreed.
>
>> 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)

> Besides speed, is there any reason at all to allocate on the stack?

Speed isn't a good enough reason?

> 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?

> 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.

>> I don't see the utility in static opCall, I say abolish/remove it.  
>> Non-static opCall on the other hand can be quite useful.
>
> But there is utility in static opCall in structs; having them there but  
> not in classes doesn't sound to cool/consistent..

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.

Regan



More information about the Digitalmars-d mailing list