www.caravan.net/ec2plus/rationale.html
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. 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. We must eliminate any specification not authorized by ANSI/ISO. 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++. 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. This means that if one looks only at the declaration, judgement concerning whether or not it is really 'const' is impossible. 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. However, there are some drawbacks for embedded systems programmers. It is difficult to estimate the time between when an exception has occurred and control has passed to a corresponding exception handler. 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. 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. 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. Therefore, the size of application programs cannot be very large. 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. However if used carelessly, templates might cause unexpected code explosion. We reiterate that program size is critical for embedded systems applications. 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. 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. 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. 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. 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. Regarding string libraries, 'string' class which is equivalent to typedef basic_string<char> string; The reason is that string libraries is used generally, useful for the embedded application and necessary for the support in Embedded C++. Regarding complex libraries, 'float_complex' and 'double_complex' which are equivalent to typedef complex<float> float_complex; The reason is that the importance of the complex libraries is increasing for the embedded application and necessary for the support in Embedded C++. Regarding stream libraries, 'istream' and 'ostream' which are equivalent to typedef basic_istream<char> istream; The reason is that the minimum stream library for input/output is necessary for debugging. 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. Therefore, the technical committee decided not to include libraries for file-operations in the Embedded C++ specification. Therefore, the technical committee decided not to include localization libraries in the Embedded C++ specification.
|
http://csua.com/feed/