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: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,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 From: James Kanze Subject: Re: Ada vs C++ vs Java Date: 1999/01/15 Message-ID: <369F0592.94F9DDDA@dresdner-bank.com>#1/1 X-Deja-AN: 432879487 Content-Transfer-Encoding: 8bit References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@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-15T00:00:00+00:00 List-Id: John Birch wrote: |> On Thu, 14 Jan 1999 13:06:27 +0100, Gerhard Menzl |> wrote: |> >Erik Funkenbusch wrote: |> > |> >> >- be suitable for design of embedded systems |> >> |> >> C++ generally isn't. There is an "embedded C++" that's in the works, and |> >> there might even be some implementations. C is better for embedded work |> >> than C++. |> > |> >This claim is completely unfounded. |> 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! Not really. I've done a lot of embedded system work in the past. I agree that for many applications, any use of dynamic memory is out (and for most others, a significant part of the code is in a critical path where use of dynamic memory is out). But C++ without dynamic memory is still a win. If only because of the access controls. (While most use of polymorphism is based on dynamic memory, there are cases where it too can be useful without dynamic memory. For example, very system I've seen emulates virtual functions in one way or another for low level hardware access.) |> Since I do not regard dynamic memory allocation as a _good_ thing for |> most hard embedded systems, I find this claim well founded :-) |> > Since C is "for all practical purposes" (as Bjarne Stroustrup puts |> >it) a subset of C++, there is no reason why C should be a better |> >choice, providing compilers are available for both |> >languages. Whether certain *features* of C++ such as templates or |> >exceptions can be reasonably used on embedded systems is a matter of |> >debate. Curiously enough, templates are one of the features which could be used on an embedded system. If anyone ever figures out how they work. |> Except that a perfectly valid ANSI C program need not compile or |> execute correctly under C++. Consequently, if it's a subset, it's a |> pretty poor one! While it is easy to conceive of valid C programs which will not compile as C++, well written, maintainable C programs which don't compile are the exception. In practice, the only reason I can think of why one might prefer C over C++ in an embedded environment is tha availability of compilers. And of course, for what you seem to mean by "embedded programs", Java is out, and Ada is probably better than C++. -- 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