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: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,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: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public From: Ola Liljedahl Subject: Re: Ada vs C++ vs Java Date: 1999/01/15 Message-ID: <369F06F5.C29BCECB@enea.se>#1/1 X-Deja-AN: 432881464 Content-Transfer-Encoding: 7bit References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77mu1h$n6m$1@galaxy.mchh.siemens.de> To: Wolfgang Denk Content-Type: text/plain; charset=us-ascii Organization: Enea OSE Systems AB 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-15T00:00:00+00:00 List-Id: Lots of crossposted groups. This posting probably mostly concerns comp.realtime. Wolfgang Denk wrote: > > johnb@invision.co.uk (John Birch) writes: > > >There are many embedded programmers who regard the concept of dynamic > >memory allocation in an embedded system as laughable at best and a > >terminal offence at worst. If you restict C++ in such a way (i.e. > > I think you are on very thin ice here. > But even under hard realtime you certainly will very often use > dynamic memory allocation - all variables put on the stack are using > a method of "dynamic memory allocation", aren't they? And even > malloc() has it's use here and there, especially when you do it only > once during initialization/configuration... What if the malloc() and free calls() take deterministic time? OSE's heap functions have these real-time properties and if they are not fast enough the kernel's pool functions (for allocation and freeing message buffers) are a lot faster and of course also deterministic in time. But using dynamic memory allocation increases the probability that the system will run out of memory or it at least becomes a lot more difficult to verify that it doesn't. So static memory allocation is more reliable. Stack allocation should be as reliable because it should be possible to compute the maximum stack usage and allocate a suitable stack for the process/task/thread. -- Ola Liljedahl olli@enea.se Enea OSE Systems