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: f849b,d275ffeffdf83655 X-Google-Attributes: gidf849b,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public From: "Martijn Lievaart" Subject: Re: Dynamic memory? (was Re: Ada vs C++ vs Java) Date: 1999/01/18 Message-ID: <77vi92$944@news3.euro.net>#1/1 X-Deja-AN: 434012697 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> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: EuroNet Internet 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: John Birch wrote in message <36a34176.18473393@news.demon.co.uk>... >On 18 Jan 1999 13:24:09 GMT, "Martijn Lievaart" >wrote: > > >>>There is inherent dynamic memory allocation going on here, it is >>>irrelevant whether it is satck or heap. I (the coder) did not >>>explicitly allocate memory, the language (or rather the implementation >>>of the language) did. > >>Well, you can take it to far! If you count this as dynamic memory >>allocation, you cannot use any one function as it will dynamically allocate >>a stackframe (hint: the "allocated memory" refered to above is also in the >>stack frame). Gets kinda hard to write a C program without any function! > >What would you call it then? It's not statically allocated, it's >allocated dynamically at run-time from the stack or the heap. It's >certainly memory, so it seems reasonable to call this dynamically >allocated memory. > >Now of course a function call involves the stack and results in >dynamic memory allocation, > >BUT.... > >With no recursion, > >In C the stack size can never be larger the maximum of the total of >the stack requirements of all of the functions defined. > >In other words, the worst case stack usage is if main called a >function, which called a function, which called a function ....... > >...... until all the functions in the program had been called. > >This value is easy to determine, indeed many embedded C compilers >calculate it for you. If you know what the maximum stack size your >program uses is, then you can guarantee, barring bugs, that your >program will run on target machine with that amount (or more) of free >memory. > >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. In fact, the C compiler is also free to generate temporaries on the stack and often does so. 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. 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. 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. 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. The RTL, maybe, will ask specificly, but not the language itself. And that is *exactly* the same as C. 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). 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. HTH Martijn -- My reply-to address is intentionally set to /dev/null reply to mlievaart at orion in nl