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: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,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: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public From: bs@research.att.com (Bjarne Stroustrup) Subject: Re: Ada vs C++ vs Java Date: 1999/01/14 Message-ID: #1/1 X-Deja-AN: 432729223 Sender: nntp@research.att.com X-Nntp-Posting-Host: raptor.research.att.com References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> Organization: AT&T Labs, Florham Park, NJ 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-14T00:00:00+00:00 List-Id: 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). > 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. 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. (this is followed by examples). > 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. - Bjarne Bjarne Stroustrup - http://www.research.att.com/~bs