Availability and power have driven C++'s rocketing popularity. Unfortunately, the massive size of the C++ specification can be daunting to developers and compiler writers alike. Difficulty in understanding the specification and its implementation with specific compilers can lead to the generation of unexpected code that may not be needed or tested.
The Embedded C++ (EC++) standards proposal is designed to trim the C++ specification to a more manageable size. It eliminates many of the features that may be unnecessary in the average embedded environment. As a proper subset, it won't contain additional syntax to extend the C++ standard.
Design goals for the specification include making the specification as small as possible while retaining C++'s object-oriented features, as well as avoiding features that use excessive amounts of memory. It also aims to avoid features that produce unpredictable response times, and to have all EC++ code be ROMable.
The specification's amendment style of the ISO/ANSI C++ Draft Standard is registered as SC22/WG21/N1037. The specification is a bit hard to read because it indicates what parts of the C++ standard are omitted versus a complete definition of what is included. For example, the Reserved But Excluded list above shows the C++ keywords that can't be used within an EC++ program, because the associated feature isn't supported. The keywords are still reserved, so they can't accidentally be used as variable or function names. This means that an EC++ application can always be compiled using a standard C++ compiler. The only difference is that a standard will not check for reserved but excluded names and features.
Doing Without: One major feature eliminated in EC++ from C++ is exception handling using catch and throw. The reason for this is twofold. First, it's difficult to estimate the time needed for error handling. Plus, the amount of memory required for exception handling is unknown. That said, exception handling is still a very nice C++ feature. Therefore, developers will have to carefully consider what EC++ aspects are most suitable for their particular embedded applications.
Templates and multiple inheritance are two other major C++ features that are absent from EC++. Although they are handy for generic classes and functions, it's easy to misuse templates. This results in unexpected code that can mushroom the size of an application, making it exceed the limited memory available in most embedded applications.
Multiple inheritance is a useful feature in some instances, yet it's rarely utilized by the majority of C++ programmers. It has sizable implications for initialization and casting. If used improperly, applications with multiple inheritance can be hard to maintain or reuse. Eliminating multiple inheritance also makes EC++ easier to learn. Some of the removed features will impact runtime libraries that can be employed with EC++. For example, the Standard Template Library (STL) can't be used with EC++ because templates aren't supported.
Advantages: Paring down C++ makes EC++ easier to learn and simplifies maintenance of EC++ applications. Compilers can be more aggressive in their optimizations because EC++ applications will not require various runtime features. In some cases, EC++ compilers can generate programs that are significantly smaller than the same program compiled via generic compiler C++ settings. Moreover, most implementations can apply EC++ restrictions selectively.
Not surprisingly, EC++ has garnered a significant following in the C++ vendor community. It has changed the minds of a number of programmers that would otherwise utilize C, or even an assembler, for embedded applications.
Reprints
