auto, var, raii,scope, banana

[Regan Heath]

On Fri, 28 Jul 2006 12:12:49 +0200, xs0 <xs0 at xs0.com> wrote:
> Regan Heath wrote:
>
>>> '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 :)
>
> You did - you propose that using "new" forces the allocation on the  
> heap, while not using it leaves the choice to the compiler (however, the  
> variable is then also scoped/raii/auto/banana, so there's not much  
> choice anyway).

I'm arguing semantics perhaps but all I did was say that it 'implied' heap  
allocation 'in my opinion'. My exact words were..

> Quoting "Regan Heath"..
>> '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.

Until you gave the example below (thanks for that) I did suspect that it  
was required for 'new' to heap allocate because stack allocation only  
'lives' as long as the scope in which it's allocated. So, stack allocation  
could be done for 'new' in certain cases (like the example below) to  
optimise, cool.

To me 'new' still 'implies' heap allocation. But, now I know that there  
are some situations where the compiler could stack allocate, situations  
where the object allocated by 'new' only 'lives' as long as the current  
scope.

>>>>  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?
>
> Did you look up escape analysis like I suggested?

Yes. But I still wanted an example from you :)

> Anyway, besides the obvious scoped/raii/auto/banana variables, here's a  
> simple example:
>
> void foo(Object a)
> {
>      writefln("%s", a.toString());
> }
>
> main()
> {
>      foo(new Whatever());
> }
>
> There's no reason why Whatever would have to be on the heap.

Nice. So an optimising compiler may choose to allocate 'a' on the stack.  
It can do that because the object only 'lives' as long as the scope of the  
function 'foo', correct?

>>>>> 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.
>
> Dude, what's wrong with you? Your argument was that Java programmers  
> would see an allocating expression without "new" or any other keyword,  
> and somehow magically determine that there's something to be learned. I  
> responded by saying that they (or me) wouldn't even see it as an  
> allocating expression, and for that I have a closed mind?

Your comment "You'll never convince me.. " caused my response wrt "closed  
mind". I meant no offence by it.

> You know, you're probably right, this discussion is pointless, like so  
> many others you participate in.

You seem to be atributing me with some sort of malice towards you, that's  
simply not the case. I avoid posting anything while I'm angry as I tend to  
regret it. I wasn't even angry or annoyed in this case, just curious. I  
seem to have angered you, I apologise for that.

> And I still don't get how you can even think that "" can be a better  
> indication of anything than "scope" (or any other keyword).

Then I'm doing a bad job of explaining. I believe you've missunderstood  
some of what I've tried to say (also my fault for choosing the wrong words  
to explain it)

>>>> 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.
>
> Without even reading your other post, I never said it's always better to  
> use static opCall. I'm just saying there are cases where it's cool to  
> have. But, this is basically a separate discussion anyway, so no need to  
> continue with it.

Actually I think it's important to this discussion. If static opCall is  
truly useful it makes the 'absence of new' idea rather worse than using a  
keyword. Among other things I'm trying to determine when/where static  
opCall is used, and why it's used in favour of another method (or even if  
one such method exists).

I also wanted to know when 'new' could do something other than heap  
allocate, you've answered that one, thanks.

Regan