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