Rationale for the Embedded C++ specification

1. Objective

The ultimate goal of Embedded C++ is to provide embedded systems programmers with a subset of C++ that is easy for the average C programmer to understand and use. The subset should offer upward compatibility with the full version of Standard C++ and retain the major advantages of C++. Meanwhile, the subset should fulfill the particular requirements of embedded systems designs.

To achieve these goals, the committee has established guidelines for creating the subset as follows:

1. Make the specification as small as possible while retaining the object-oriented features.
2. Avoid those features and specifications that do not fulfill the requirements of embedded system design. The three major requirements of embedded system designs are:
• Avoiding excessive memory consumption
• Taking care not to produce unpredictable responses
• Making code ROMable
3. Nonstandard extensions to C++ should be avoided. This condition is an absolute necessity. We must eliminate any specification not authorized by ANSI/ISO.
4. Our background is in the semiconductor business. We mainly target 32-bit RISC MCU applications as embedded systems. Though there are many applications using 4 or 8-bit MCUs, we cannot address them. We feel that the basic features of C, or even assembly language, are sufficient for these processors. On the other hand, those systems that are expandable using standard buses, such as VME or PCI, are similar to those of PCs or workstations. We recognize that a full version of Standard C++ is better than Embedded C++ for those application designs.

Embedded C++ is not a new language specification that will compete with existing Standard C++. Rather, it is a pure subset for the practical user of C++. It supports the establishment of a new methodology in embedded system designs, where a large number of programmers are currently involved. Although some of the above criteria may lose their relevance when new compilers using advanced technologies are available, we will not consider these possibilities for now. We should focus on the future without forgetting about the present.

Regarding Embedded C++ library, the set, which conforms to Embedded C++ syntax and semantics and does not depend on OS or environment, is supported. And the set is limited to the minimum set for the embedded application.

The compatibility with C++ is reserved except two cases:
First the rules for matching exception specifications across multiple declarations are subtle, and it is better that programmers use macros or preprocessor conditional in user's defining 'new'/'delete' functions.
Secondly, `float_complex' and 'double_complex' peculiar to Embedded C++ cannot have the compatibility with C++. Programmers have to use macros or preprocessor conditional to reserve the compatibility with C++.

2. Syntax and semantics

2.1 Mutable specifier

In embedded systems programming, an object that is specified 'const' is generally meant to be put into ROM. However, any class members declared 'mutable' can be modified, even if the object itself has been declared 'const'. Therefore, objects that belong to a class that have a 'mutable' member cannot be put into ROM.

Also, 'mutable' is specified for a class member, i.e., it is specified in the class definition, not in each object declaration. This means that if one looks only at the declaration, judgement concerning whether or not it is really 'const' is impossible.

  ex.) const class X xobj;
       // One cannot recognize whether or not the 'xobj' is really 'const'
       // until the class definition of 'X' is inspected.

Thus, a 'mutable' specifier might bewilder the average embedded systems programmer.

Therefore, the technical committee decided not to include the 'mutable' specifier in the Embedded C++ specifications.

REASON:(2)

2.2 Exception handling

Exception handling is useful for dealing with errors. However, there are some drawbacks for embedded systems programmers.

1. It is difficult to estimate the time between when an exception has occurred and control has passed to a corresponding exception handler.
2. It is difficult to estimate memory consumption for exception handling.

As control passes from a throw point to a handler, destructors are invoked for all automatic objects constructed since the try block was entered. If an object has a destructor, then it must be destroyed by calling its appropriate destructor. It is difficult to estimate the total time spent on destroying automatic objects.

In general, the exception mechanism requires compiler-generated data structures and runtime support. This sometimes adds unexpectedly to the size of the program.

In embedded systems it is important for a programmer to be able to easily estimate processing time. Small code size is also important. Therefore, the two drawbacks mentioned previously cannot be ignored for embedded systems programming.

For these reasons, the technical committee decided not to include exception handling in the Embedded C++ specifications.

REASON:(2)

2.3 Runtime type identification

To support the runtime type identification (RTTI) facility, there is at least some program size overhead, because type information for polymorphic classes is needed. The compiler automatically generates the information, and it would be included in programs that do not use the RTTI facility.

For a program that uses polymorphism heavily, the RTTI facility can provide an advantage. But in the case of programs that make little use of polymorphism and do not need the RTTI facility, it has no merit. Program size is critical for embedded systems applications. Also, programs such as the previously mentioned ones are advanced and out of the range of the Embedded C++ specifications, which aim at easy understandability and predictability of generated object code by average C programmers.

Therefore, the technical committee decided not to include the RTTI facility in the Embedded C++ specifications.

REASON:(2)

2.4 Namespace

The typical target CPU for the Embedded C++ specifications does not have much memory. Therefore, the size of application programs cannot be very large. Under such conditions, names seldom, if ever, come into conflict.. If name conflict becomes a serious problem, we can avoid it by using static member of a class. Namespace facility is not essential for the Embedded C++ specifications.

Therefore, the technical committee decided not to include it in the Embedded C++ specifications.

REASON:(1)

2.5 Template

Templates are useful for making generic classes or functions. However if used carelessly, templates might cause unexpected code explosion. We reiterate that program size is critical for embedded systems applications. Furthermore, they may increase the time of compilation. Lastly, efficient use of templates depends on programmers having a high level of experience, which means that they will have to invest a great deal of time to learn them well.

Therefore, the technical committee decided not to include template in the the Embedded C++ specifications.

REASON:(2)(1)

2.6 Multiple inheritance and virtual inheritance

It is difficult even for an expert programmer to design a class hierarchy using multiple inheritance, or to recognize the overall hierarchy of it and use it correctly. Programs that do not use multiple inheritance appropriately tend to be less readable, less re- usable, and more difficult to maintain.

The Embedded C++ aims at providing specifications that are easy to learn and are used in actual embedded systems programming. Multiple inheritance does not fit this principle.

Therefore, the technical committee decided not to include multiple inheritance in the Embedded C++ specifications.

Virtual inheritance makes sense only if multiple inheritance is used, so virtual inheritance is also absent from the Embedded C++ specifications.

REASON:(1)

3. Library

3.1 Exception

Since the exception is out of Embedded C++ syntax and semantics, libraries with exception are not supported as the Standard Embedded C++ library.

However 'new' with exception specification is supported. The reason is that the dynamic memory allocation is necessary.

The specification of 'new' is referred by the amendment in detail.

Therefore, the technical committee decided not to include libraries with exception in the Embedded C++ specification.

REASON:(2)

3.2 STL

Since the template is out of Embedded C++ syntax and semantics, libraries with template (the Standard Template class Libraries) are not supported.

Therefore, the technical committee decided not to include the standard template class libraries in the Embedded C++ specification.

Some classes are partly supported as non-template class libraries. 1)

1)Classes 'string', 'complex', 'ios', 'streambuf', 'istream' and 'ostream' are supported in the Embedded C++ specification. The reasons are followed.

Regarding string libraries, 'string' class which is equivalent to

typedef basic_string<char> string;

Regarding complex libraries, 'float_complex' and 'double_complex' which are equivalent to

typedef complex<float> float_complex;
typedef complex<double> double_complex;

Regarding stream libraries, 'istream' and 'ostream' which are equivalent to

typedef basic_istream<char> istream;
typedef basic_ostream<char> ostream;

REASON:(1)(2)

3.3 wchar_t, long double

The libraries for type of wchar_t or long double are little used for the embedded application and have little necessity in the present circumstances.

Therefore, the technical committee decided not to include libraries for type of wchar_t or long double in the Embedded C++ specification.

For example, 'wstream', 'long_double_complex' are not supported.

REASON:(2)

3.4 File-operations

The libraries for file-operations are not supported because of dependence on OS.

Therefore, the technical committee decided not to include libraries for file-operations in the Embedded C++ specification.

REASON:(2)

3.5 Localization libraries

The localization libraries need much memory, are inconvenient to users and have no necessity for most embedded environment.

Therefore, the technical committee decided not to include localization libraries in the Embedded C++ specification.

REASON:(2)