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: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,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: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public From: Scott Johnson Subject: Re: Dynamic memory? (was Re: Ada vs C++ vs Java) Date: 1999/01/26 Message-ID: <36AE7BA5.46B@nospam.aracnet.com>#1/1 X-Deja-AN: 437354880 Content-Transfer-Encoding: 7bit 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> <36A36CA2.6912DA15@west.raytheon.com> Content-Type: text/plain; charset=us-ascii Organization: National Association for the Advancement of Computer Geeks Mime-Version: 1.0 Reply-To: sj_nospam@nospam.aracnet.com 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-26T00:00:00+00:00 List-Id: Ken Keys wrote: > > John Birch wrote: > > > In C the stack size can never be larger the maximum of the total of > > the stack requirements of all of the functions defined. > > And the heap requirements can never be larger than the maximum of the > total of the heap requirements of all of the functions defined. Indeed > in that case even fragmentation is not an issue because you can assume > that memory is never freed and just add up all the allocations. Except for one thing: Consider the following function: int *get_an_array_of_ints (int size) { int *retval; retval = (int *) malloc (size * sizeof(int)); if (!retval) printf ("Oh shit. Out of memory.\n"); return retval; } The amount of stack space this needs can be determined at compile time-- and is likely very small for this function. (Little more than a frame pointer; all of the variables can likely fit in registers if the optimizer is turned on, and you are not using certain brain-dead processors, commonly found "inside"). :) The amount of heap needed by this function depends on the input parameter, and is unbounded. At any rate, trying to statically analyze a program (in the general case) for heap requirements is, as CS profs like to put it, "computationally equivalent to the halting problem." In other words, mathematically impossible. (At least its impossible to do so in a finite amount of time; most project managers I know would be rather unhappy were the schedule to slip to the Apocolypse and beyond while dynamic memory requirements were being analyzed.) > > Now try telling me how to calculate a worst case C++ memory > > requirement. > I don't see how the equation would be any different in C++ than in C > except that there is a tendency to use the heap more in C++. 'Tis the only real difference. Outside possibly of exceptions, I cannot think of any language feature that results in new() or delete() being called behind the scenes (or that needs to, at least.) > In C it is considered bad form to allocate really big data structures > on the stack but there is nothing in the language that prevents it. If > you limit the stack usage to the most benign objects and put the big > stuff on the heap, it makes your worst case stack look better. Of course, 'tis doesn't matter if you run out of stack or out of heap. Running out of either is fatal for many an embedded system. Scott