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