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: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public From: "John Birch" Subject: Re: Ada vs C++ vs Java Date: 1999/01/16 Message-ID: <77pnqc$cgi$1@newnews.global.net.uk>#1/1 X-Deja-AN: 433281411 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77ledn$eu7$1@remarQ.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 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-16T00:00:00+00:00 List-Id: Pat Rogers wrote in message <77ledn$eu7$1@remarQ.com>... I originally wrote >>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. >>prevented the use of dynamic memory allocation) you'd pretty much end >>up with C anyway! >> >>Since I do not regard dynamic memory allocation as a _good_ thing for >>most hard embedded systems, I find this claim well founded :-) You replied; >While I certainly agree that the default implementation -- in both Ada >95 and C++ -- for dynamic allocation is probably not desirable in a >real-time environment, in both languages once can easily define how >allocation is done while still using the language's syntax (i.e., >"new", in both). As a result allocation can be completely >deterministic, without resorting to user-defined functions. So "don't >throw the baby out with the bathwater" as the saying goes. I feel the issue here is whether you regard any form of run-time memory allocation a good thing! Whether it is by overriding new is irrelevant. The very act of designing a program that is not explicitly coded with a known memory requirement precludes it's use in a system that does not provide a virtual memory mechanism. Of course a lot of this depends on your 'view' of the meaning of embedded system. I still hold to the early definitions that an embedded system comprised of a CPU, IO (serial / parallel), RAM and ROM (and limited quantities of it ;-)). At present the term embedded system has come to encompass even high powered computer systems (at what might be called mini computer level) providing they are placed in an unusual environment e.g. an aeroplane. This has led to the proliferation of 'embedded solutions' that use virtual memory, disk I/O and operating systems, all of which IMHO encourage a 'never, never approach' to coding. By this I mean that instead of working within unbreakable memory constraints with static data, programmers choose to produce solutions that are more open. Whilst initially this appears a more laudable approach, in the domain of critical software it is potentially disastrous. What do you do at Mach 2 if your flight control system decides it needsmore memory because the mission duration is six seconds longer than the software designer anticipated. If you are confident that by using C++ you can absolutely determine the memory footprint of your code under all conditions, then by all means feel free to use it, but don't expect me to fly with you! I will stick to using C, static memory structures, avoid pointers unless absolutely necessary and feel safer for it ;-). regards John Birch (at home)