auto, var, raii,scope, banana
Regan Heath
regan at netwin.co.nz
Thu Jul 27 14:51:46 PDT 2006
On Thu, 27 Jul 2006 15:31:24 +0200, xs0 <xs0 at xs0.com> wrote:
> 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")
Ok.
>>> 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.
Exactly. I never suggested otherwise :)
>>> 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.
Example?
>>> 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.
Have you read my other post?
Are you telling me you have a "closed mind"?
If so, this discussion is pointless.
>> 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.
Yes, but it's a 'static' function. See my other post WRT "information
hiding", for that purpose it's actually better to use an actual static
function.
Regan
More information about the Digitalmars-d
mailing list