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: 1108a1,d275ffeffdf83655 X-Google-Attributes: gid1108a1,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 101b33,d275ffeffdf83655 X-Google-Attributes: gid101b33,public 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 From: "John Birch" Subject: Re: Ada vs C++ vs Java Date: 1999/01/16 Message-ID: <77polf$d5i$1@newnews.global.net.uk>#1/1 X-Deja-AN: 433283204 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> 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: Bjarne Stroustrup wrote in message ... >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. >For many embedded systems this is clearly true. For other embedded systems >some limited and controlled forms of (special purpose) dynamic allocation >are acceptable. (``embedded systems'' is a term that covers a lot of >diverse applications). Indeed, but my personal experience is with small embedded hard real-time systems. In such a problem domain the above statement I feel holds true. > > 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! >This is simply wrong. The better type checking, uses of classes for concrete >types and many forms of data abstraction, and templates do not depend on >dynamic memory. You can even use polymorphism to simplify code using >statically allocated objects of a variety of types. The use of C++ without dynamically allocated classes will obviously provide extra featues over C. The issue as to whether it is better to use a 'crippled' C++ is a question of debate and will surely depend on the problem to be solved and the calibre and organisation of the team of programmers working on it. In my experience, the restriction of language features in a project is difficult to control. I agree my original statement was somewhat inflamatory though >Many embedded programs have been written in C++ styles that go way beyond >the styles directly supported by C. > > > 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. >Here is the way I address the "Is C a subset of C++?" question in my FAQ: > In the strict mathematical sense, C isn't a subset of C++. > There are programs that are valid C but not valid C++ and even > a few ways of writing code that has a different meaning in C > and C++. However, C++ supports every programming technique > supported by C. Every C program can be written in essentially > the same way in C++ with the same run-time and space efficiency. > It is not uncommon to be able to convert tens of thousands > of lines of ANSI C to C-style C++ in a few hours. Thus, C++ is > as much a superset of ANSI C as ANSI C is a superset of K&R C > and much as ISO C++ is a superset of C++ as it existed in 1985. The comment I made was to pick up on the use of the term subset. Your quote above qualifies the statement perfectly and it is perhaps a pity it was not included in the originally post :-) > > 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! >In the context of embedded systems, consider the two most annoying >incompatibilities when you consider C as a ``for practical purposes'' >subset of C++: > If you don't use function prototypes in C, your program won't > compile as C++ - and most would consider the program sloppy > for having failed to use the type safety offered by the prototypes. > If you don't cast the result of malloc() and realloc(), your > program won't compile as C++ - and for many/most embedded > applications you shouldn't use malloc() anyway. Agreed, any C program that would not compile with minimal changes under C++ would be one that I would not be over proud of! Finally, It was never my intention to denigrate your efforts in the development of the C++ language, rather I wished to emphasise that there is a spectrum of tools and a spectrum of problems. Not all tools fit best against all problems. Unfortunately, there seems to be a bit of 'If the only tool in the toolbox is a hammer, then everything looks like a nail' in the choice of languages for a project.