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,FREEMAIL_FROM, 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: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public From: Herman Subject: Re: Ada vs C++ vs Java Date: 1999/01/15 Message-ID: <369F59FD.3718@telusplanet.net>#1/1 X-Deja-AN: 432959569 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> Content-Type: text/plain; charset=us-ascii X-Trace: news2.telusplanet.net 916409310 161.184.46.206 (Fri, 15 Jan 1999 07:08:30 MDT) Organization: Aerospace Software Ltd. MIME-Version: 1.0 Reply-To: aerosoft@telusplanet.net NNTP-Posting-Date: Fri, 15 Jan 1999 07:08:30 MDT 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: One can get fairly predictable memory management results if one uses a partitioned approach with fixed block sizes. We have used that approach with VRTX on airborne products and it proved to be reliable. Cheers, Herman 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. > > First, I gues you really were thinking of "hard realtime require- > ments", which is a somewhat different issue. Many embedded systems > don't have realtime problems (but of course there are many others > that do). > > 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... > > Wolfgang Denk > > -- > Office: (+49)-89-722-27328, Fax -36703 Wolfgang.Denk@icn.siemens.de > Private: (+49)-89-95720-110, Fax -112 wd@denx.muc.de > Another dream that failed. There's nothing sadder. > -- Kirk, "This side of Paradise", stardate 3417.3