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: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public 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: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,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: <36a37125.30679685@news.demon.co.uk>#1/1 X-Deja-AN: 434065855 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> <36a357bb.24173519@news.demon.co.uk> X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 916681450 nnrp-04:19088 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 16:10:58 GMT, johnb@invision.co.uk (John Birch) wrote: I wrote (erroneously) >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? I just realised what I wrote here, and it's wrong. There is no need to code operator + as calling new, indeed to do so would be to create a memory leak in the above example! I apologise unreervedly for any confusion caused. However, there is still a requirement to allocate memory on the stack so that operator + can return a value rather than a reference to a local variable. The point is, does, and can the compiler tell me the programmer how much memory each function is going to need to execute, and can I rely upon tricks like adding the numbers up to give me the overall footprint. >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. In a sense my point is proven. It is these kind of complexities that make it difficult to use C++ in a hard embedded environment, where you need to have a real grasp of what the code is going to do. Maybe I'm just to dyed in the wool tho' :-) regards John B.