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 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: James Kanze Subject: Re: Ada vs C++ vs Java Date: 1999/01/18 Message-ID: <36A36FC8.5F5A75F8@dresdner-bank.com>#1/1 X-Deja-AN: 434061989 Content-Transfer-Encoding: 8bit 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> <36A35B48.F88B0CB9@dresdner-bank.com> <36a364ff.27569452@news.demon.co.uk> X-Accept-Language: fr,en,de Content-Type: text/plain; charset=iso-8859-1 Organization: Dresdner Bank Mime-Version: 1.0 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: |> On Mon, 18 Jan 1999 17:03:21 +0100, James Kanze |> wrote: |> >John Birch wrote: |> >|> The reason IMHO is that C++ inherently relies upon dynamic memory |> >|> allocation! |> > |> >I'm curious as to what makes you say this. |> Simple, every creation of a non static object in C++ causes a dynamic |> memory allocation, whether by explicitly calling new, or by the |> creation of temporary objects as a side effect of operator calls. This |> memory is allocated from the stack or the heap (makes no difference |> really, it's still memory). Obviously. This is true of C as well, and of any other language you can name. If you create an object, you must have some where to put it. And if the language supports recursion (whether your program recurses or not), then that somewhere is, almost by definition, on the stack. |> > It's probably true that most |> >C++ programs do make extensive use of dynamic memory, but then, it's |> >probably ture that most C programs also make extensive use of dynamic |> >memory. |> Only if dynamic memory is present. It usually requires an OS to |> support it, although I have seen people develop their own heap |> management software for hard embedded stuff (they're still working on |> why their software falls over after x hours ;-). OK. You're talking about a non-hosted environment, not the C that most people use. And even a non-hosted environment is required to support recursion, so there will at least be a stack. |> The reasons I dislike dynamic memory management are two-fold, first, |> it encourages a never, never approach to coding (ie. there is a |> tendency to write for the general case, rather than explicitly |> calculating and coding for the appropriate limitations), and secondly, |> what do you do to prevent heap fragmentation. Please don't suggest |> garbage collection because you can't guarantee that it has run when |> you need to create that big object that would have fitted into the |> heap ten seconds ago, and would now if the memory wasn't fragmented |> and how do I tell the code that the pointer I gave it has moved and Oh |> Ohh Hello ground....... There are places where dynamic memory management is inappropriate. I never said anything else. But the rules for when and where dynamic memory will be used in a program are basically the same in C and C++: both are required by the standard to have some sort of a stack, both are required to have some sort of a heap (at least in a hosted environment), and neither is allowed to use the heap *unless* the programmer either explicitly asks for it, or calls a library function which is allowed to dynamically allocate memory (which means just about any function in the standard library). Having worked on processors with as little as 64 bytes of memory, I can imagine that compilers for such processors may offer compromises with the standard, even to the degree of forgoing support for a stack. But there is nothing to prevent a C++ compiler from making the same compromises. -- James Kanze GABI Software, S�rl Conseils en informatique orient� objet -- -- Beratung in industrieller Datenverarbeitung mailto: kanze@gabi-soft.fr mailto: James.Kanze@dresdner-bank.com