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: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public 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: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: johnb@invision.co.uk (John Birch) Subject: Re: Dynamic memory? (was Re: Ada vs C++ vs Java) Date: 1999/01/18 Message-ID: <36a357bb.24173519@news.demon.co.uk>#1/1 X-Deja-AN: 434032654 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> <77vclp$rme@news3.euro.net> <36a34176.18473393@news.demon.co.uk> <77vi92$944@news3.euro.net> X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 916675892 nnrp-03:2032 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 18 Jan 1999 14:59:46 GMT, "Martijn Lievaart" wrote: >>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 try telling me how to calculate a worst case C++ memory >>requirement. >It is more difficult, but the temporaries in the example above are also >allocated on the stack, so the same argument as in the C case still holds. 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. >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. > I think that the main reason why the compiler/linker will >calculate the maximum stacksize for you (the embedded scenario you >described) is not as a convenience to users, but because the user cannot >know in advance what stack usage his program has. Only the compiler knows >this. No, the main reason is exactly as I stated it, it is to tell embedded programmers how much stack space a program will use. The value of the stack space as calculated by the compiler is used by the linker to locate various portions of the code generated by the compiler and to check that heap, initialised data and stack space do not overflow available memory. >Let me repeat, this is exactly the same as a C compiler. F.i. take the >following code. >int f(int i1, int i2, int i3) >{ > return i1+i2+i3; >} >On a register poor machine (not likely, but it might) this certainly will >allocate temporaries on the stack. 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. > This is exactly the same as the example >that started this thread, only no function calls to an user defined operator >but a hardcore integer-add instruction. As I've shown it is in fact different! > But *no more* dynamic memory >allocation than in this C example. (yeah, user defined operators are >function calls, so these take a stack frame, but that is the same as you >calling a function in C, i.e. predictable and reportable by the compiler). >Not even mentioning the fact that a good (embedded) C++ compiler might even >only use registers in most cases. >In fact, C++ will *never* dynamically allocate memory on your behalf if you >don't explicitly tell it to. This depends on your definition of explicit. In order to code the above example, the operator + function has to call operator new (indeed it has to be a friend function too). So there is an explicit call to allocate memory. The point I am trying to make is how do you work out how much memory is used by a C++ program? >The RTL, maybe, will ask specificly, but not >the language itself. And that is *exactly* the same as C. It is a language feature (operator overloading) that creates the problem in the first place by encouraging such coding styles. One of the core tenets of C programming is the 'nothing up my sleeve' approach, C++ does not have this requirement that the programmer has visibility of every action taken by the code. This I feel is a major disadvantage when coding for resource limited hardware. > I remember >Stroustrup commenting on this as one of the myths hardcore C programmers >have against C++, but I'm to lazy to look it up right now so don't quote me >on it (yet). I'd love to see it if you can find it. >Mind you, I'm not saying C++ is a better or even viable alternative, but I >do want to get these myths out of the way. Calling it a myth does not make it go away ;-) regards John B.