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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: johnb@invision.co.uk (John Birch) Subject: Re: Ada vs C++ vs Java Date: 1999/01/18 Message-ID: <36a36bc1.29299700@news.demon.co.uk>#1/1 X-Deja-AN: 434061988 X-NNTP-Posting-Host: invision.demon.co.uk:158.152.59.42 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <369F0592.94F9DDDA@dresdner-bank.com> <77pnr4$ch3$1@newnews.global.net.uk> <36a3281a.11980677@news.demon.co.uk> <36A35D67.412F4820@dresdner-bank.com> X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 916680764 nnrp-05:29653 NO-IDENT invision.demon.co.uk:158.152.59.42 Reply-To: johnb@invision.co.uk 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-18T00:00:00+00:00 List-Id: On Mon, 18 Jan 1999 17:12:23 +0100, James Kanze wrote: >|> OK, say I have the following; >|> Complex one (1), Complex two (2), Complex three (3), Complex four (4); >|> Complex Sum; >|> Sum = one + two + three + four; >|> If Complex is a class with an overloaded + operator, I get temporary >|> objects generated (possibly at the compiler's option) in the above >|> statement. Since it can be written as; >|> Sum = operator + (operator + (operator +(one, two), three), four); >|> Now where do these temporary objects get created? On the stack, or on >|> the heap. >On the stack. >|> In C the stack size (without recursion) can never grow beyond the >|> maximum of the total of the stack requirements of all of the functions >|> defined. >The rules concerning the growth of stack size are the same in both C and >C++. In particular, change the name of the function in the above to >addComplex, and there is really no difference in this case between C and >C++. The expression: > Sum = addComplex( addComplex( addComplex( one , two ) , three ) , four ) ; >in C will require at least three instances of Complex as temporaries on >the stack. In a C compiler, addComplex would return a struct (as a value) and take two structs as values. However they would be passed by reference (by the compiler). But in C the calling function would create the necessary stack space and pass addComplex a 'pointer' to where it wanted the answer put. Usually using a register specifically dedicated for such a purpose. So the routine that included Sum = addComplex(addComplex(addComplex(one , two) , three) , four) ; when compiled would report a stack requirement that included the space necessary for any temporary variables (because the size of the return type is known). In C++ the Complex operator + function must return an object by value since a local reference can't be returned (and it has to be a friend function as well!). Are you saying this goes on the stack? >|> How do I calculate the potential stack size in C++? >Exactly like you do in C. So are you saying that a C++ compiler will report the stack and heap requirements of any function in a way that I can use to determine memory usage of a program? regards John B.