From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f5d71,d275ffeffdf83655
X-Google-Attributes: gidf5d71,public
X-Google-Thread: f849b,d275ffeffdf83655
X-Google-Attributes: gidf849b,public
X-Google-Thread: 103376,d275ffeffdf83655
X-Google-Attributes: gid103376,public
X-Google-Thread: 146b77,d275ffeffdf83655
X-Google-Attributes: gid146b77,public
X-Google-Thread: 115aec,d275ffeffdf83655
X-Google-Attributes: gid115aec,public
X-Google-Thread: 109fba,d275ffeffdf83655
X-Google-Attributes: gid109fba,public
X-Google-Thread: 101b33,d275ffeffdf83655
X-Google-Attributes: gid101b33,public
X-Google-Thread: 1108a1,d275ffeffdf83655
X-Google-Attributes: gid1108a1,public
From: stanley@West.Sun.COM (Stanley Friesen [Contractor])
Subject: Re: Dynamic memory? (was Re: Ada vs C++ vs Java)
Date: 1999/01/20
Message-ID: <783all$2rq@abyss.West.Sun.COM>#1/1
X-Deja-AN: 435138854
References: <369C1F31.AE5AF7EF@concentric.net>
 <36a34176.18473393@news.demon.co.uk> <77vi92$944@news3.euro.net>
 <36a357bb.24173519@news.demon.co.uk>
Organization: SunSoft South, Los Angeles, CA
Newsgroups: 
 comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java,comp.java.advocacy,comp.realtime,comp.arch.embedded,comp.object,comp.lang.java.programmer
Date: 1999-01-20T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <36a357bb.24173519@news.demon.co.uk>, John Birch <nospam> wrote:
>No, it does not! The temporary objects created above are as a result
>of calls to an object constructor. There is no parallel in C to a
>constructor. The only stack usage in C results from function calling.

This depends on the C compiler and the input soruce code.

Having disassembled a fair number of compiled C programs, I can attest
that C compiler may generate tempraries on the stack for intermediate
results in a complex expression.  The fewer registers on a given machine,
the more likely it is to do so.  One one machine I used an expression
like (a * b) + (c * d) would use a stack temp.
>
>>In fact, the C compiler is also free to generate temporaries on the stack
>>and often does so.
>
>Whilst it may use the stack space for temporary values, this space is
>pre-allocated in the stack requirements for any given function call. A
>C compiler AFAIK will never extend the size of the stack frame within
>a given function.

Well, block-local variables can do something akin to that. While
many compilers precalculate the maximum size required for all block-locals
and set the stack size that, some treat the stack size as varying.
>Yes it might, but the compiler will include any stack space it is

>using as registers into the stack requirements for function f(). In
>the C++ example the compiler may not know how big the temporary
>objects are going to be.

Umm, how not?  The standard explicitly forbids passing incomplete types
to a function (such as an operator), which means the C++ compiler *does*
know how big they are.  (Even if the class uses new() internally, that
doesn't allocate on the stack anyhow).

[Check it out: both the lvalue-to-rvalue conversion and binding to a reference
require a complete type, and those are the only two ways to pass something
to an operator function].