Form S100-1092a 9X&CPLUS.HLP Ada Information Clearinghouse, 1-800-AdaIC-11, 703/685-1477 CONTRASTS: Ada 9X and C++ Edmond Schonberg NYUAda 9X Project New York University 251 Mercer Street New York, NY 10012 Schonberg@cs.nyu.edu April 22, 1992 1. Introduction Ada 9X and C++ are modern general-purpose languages of roughly similar power, aimed broadly at the area of Systems programming. Ada 9X, like Ada, is also intended for embedded and real-time systems, and has a number of built-in features to support concurrent and distributed programming. Both Ada 9X and C++ have features that modern software engineering practice considers indispensable: modularity, information hiding, structuring tools for large programs, inheritance and support of object-oriented design methods, various mechanisms for parametrizing software components, etc. Both languages are clearly superior to their competitors (C, Modula-2 Pascal, Eiffel) in terms of expressive power, maturity, and software base. Ada is also superior to these in terms of safety and reliability. We will show that Ada 9X has similar advantages over C++, in particular when software costs are examined over the lifetime of the software system. Rather than being comprehensive, we choose to focus on details where the philosophies of both languages are in sharpest contrast. We will often use Ada rather than Ada 9X in the discussion, because many of the best features of Ada 9X are simply inherited from its parent. 2. Anything you can do, I can do as well The comparison of programming languages is in part a subjective affair; judgements are influenced by personal stylistic choices, by familiarity, by the well known first-language effect, etc. Given that all programming languages in use are Turing-equivalent, no claim can be made as to the absolute advantage of one over the other. Rather, the arguments have to be pragmatic ones: reliability, ease of use, and modifiability of the resulting software. Social considerations are also relevant: the programming culture, the training of programmers, the availability of tools, the mechanisms by which programming idioms circulate through the community, etc. For example, consider the question of library management, a vital issue in every sizable project. The integrity of an Ada system is protected first by the library mechanism, whose definition is an integral part of the language. Every large project will build on top of the library management some configuration control machinery which simplifies the coordination of the work of many programmers, but the first guarantee of reliability is that the Ada system itself will not let you build a system with out-of-date components. The C++ programmer (or the C programmer for that matter) will claim that he obtains the same effect by the use of the Make utility and by the disciplined naming conventions of the header files. This is true, but the point I want to make is that to replicate the mechanisms that Ada supplies takes more than C++: it requires a number of utilities and tools that are common in the Unix environment, but are in no way standardized and are not part of the language. Thus there are no semantic checks on their use, and no relationship between these tools and the language translator itself. C and C++ depend critically on their environment. This has two consequences: 1. When judging the size of the language (as in the frequent complaint: "Ada is too big") one must consider that competent use of C++ requires much more knowledge than just the language; it requires comparable familiarity with a number of tools in the environment. The aggregate baggage is larger than for Ada or Ada 9X (given that the size of C++ alone is already as large as Ada 9X, and at least as complex). 2. Second, even if implementations of the language are standardized (which is far from true for C++) differences in the environment and its tools make portability harder to achieve. Programs can easily become contaminated with environmental details. To the C++ programmer who says: "this is no problem, because if you just follow coding conventions the problems disappear", we can only reply that these coding conventions are additional baggage that the programmer must know, that they add to the cost of using the language, and that they are inherently less safe than comparable features that are built into the language. 3. Finally, the programmer's knowledge is less portable and thus devalued, because a solution adopted in one shop will be foreign to another. We conclude that the C++ culture requires a larger aggregate knowledge than the Ada culture, that this knowledge is ill-defined at the interface between language and environment, and that it results in lessened portability and thus greater maintenance costs than comparable Ada software. 3. The type model: what is an array? In spite of the fact that arrays are one of the oldest composite types in programming languages, there are sharp differences between their realization in C++ and Ada. C++ follows the C approach: arrays are closely related to pointers, and the indexing operation is described directly in terms of pointer arithmetic. This has several consequences: 1. The indexing operation is not automatically checked. The language reference indicates that out-of-bounds indices are illegal, except that it is allowed to point one element past the end of the array (for reasons having to do with common programming idioms for iterating over an array); but there are not automatic bound checks at run-time. Given that indices out of bounds are the most common type of run-time error, this makes the use of arrays in C++ inherently less safe than in Ada. 2. There is no array assignment: if an array is a pointer, then an assignment to the name of the array is a pointer assignment which aliases the array, not a data transfer operation. 3. Multidimensional arrays are defined as arrays of arrays; multidimensional arrays must be declared with constant bounds (after the first) and have no built-in descriptors (such as Ada requires to support array attributes). Linear algebra packages for example must carry explicit size parameters, or else the user is forced to play aliasing tricks between one- and multi-dimensional arrays, as is done in FORTRAN. Thus the basic data type of scientific programming is described in low-level storage terms. In contrast, multidimensional arrays in Ada are described in terms of formal operations of an abstract type. In this area, C++ is clearly a lower-level language. 4. All array types have the same index type; one cannot define an array over an enumerated type, and there is never any type checking on indices. Shortcoming 1) in particular is well-known and acknowledged by the C++ community. Stroustrup [S91] correctly describes arrays as low-level structures and presents a user-defined vector class (on which indexing is checked) as a better abstract type. Unfortunately, the proper implementation of the class requires exceptions, a feature which has only recently been introduced into C++ and which is not widely (nor consistently) implemented yet. In the meantime, programming without index checking is akin to driving without seat belts on the optimistic conviction that most drivers are sober. This optimism pervades the C and C++ communities. Ada programmers are more wary of their surroundings. We should also remark that compilers make a big effort to optimize the use of built-in arrays, because they are the basic structure of many compute-intensive programs. Compilers are much less likely to treat user-defined arrays with the same care (there are no anticipated versions of LINPACK that use C++ vector classes). We conclude that C++ software is less reliable than Ada and Ada 9X code, and that for scientific programming C++ is a lower-level language than Ada. 4. Classes, Inheritance, and Objects Object-oriented programming and design (OOP) has become the buzzword of the decade. Behind the obvious enthusiasm of the software community there lies the correct perception that OOP simplifies the design and construction of software systems. The basic reason is ease of reuse. The notion of object is vague and has been used to mean variously abstract type active agent, message receiver, etc. (A good case can be made that Ada tasks are the perfect model for objects and that Ada was one of the earliest object-oriented languages.) But in fact the usefulness of OOP does not lie in this fuzzy notion of object. Rather, it lies in the combination of inheritance, specialization by extension, and dynamic dispatching. The gain is in the amount of code that one does not have to write, simply because one can obtain it by inheritance from the previously defined software component. Inheritance was already present, in a rigid form, in the type derivation mechanism of Ada 83. OOP brings the fundamental insight that types should be enriched by extending what they inherit, rather than being mere copies of their ancestors. Dynamic dispatching, that is to say the type-safe run-time choice of the operation that applies to a specific type extension, is real innovation in software construction. Ada 9X implements OOP by a straightforward extension of the notion of derived type [AMSR]. Objects are no different from Ada83: they are entities that can have values of a certain type. The message-passing concept can still be realized by means of tasks, but the more conventional concept of class is the Ada 9X type extension: type new_and_improved is new tried_and_true with record this: bell; that: whistle; end record; procedure ring(thing: new_and_improved) is ... The type new_and_improved inherits the primitive operations of its parent type tried_and_true. Those operations act on the components that are common to both parent and child types. In addition, the new type contains additional components (bells and whistles) and one can define new operations (or override inherited ones) which make use of the components in the extension. There is no special syntax to designate objects of such types, nor to invoke operations that have formals of such types. Furthermore, if the parent operation has several parameters (or return value) of the parent type, then the signature of the inherited operation is obtained by replacing every mention of the parent type with the child type. As in most other OOPLs, Ada 9X makes some basic distinctions between types that can be extended in this fashion (tagged types) and types that cannot (for example integers). In contrast, the notion of class in C++ derives from that of structure, and suggests that subprograms that apply to objects of a class are in some sense part of those objects (class members). This model, inherited from Smalltalk and Simula, gives a privileged role to the first parameter of such a subprogram, which is invoked with a special notation (as a qualified name). In our experience, it is seldom useful to think of the operations as being part of a value (unless they are entries in a task). The Ada 9X model provides the benefits of OOPS without this somewhat muddled notion of object. Note also that C++ classes are the only encapsulation mechanism in the language (if one excludes the use of files as modules), and thus they also play the role that packages play in Ada. This dual role is better served with two separate notions. 4.1. Family interactions The Ada 9X model also provides a more natural description of binary operations (and in general operations that have several formals of the same tagged type). Consider: function merge(x, y: parent) return parent ; ... type child is new parent with record ... -- function merge(x, y: child) return child is inherited. In the C++ model the member function has an implicit first parameter: class parent { ... parent merge(parent) ... } class child: public parent { ... The class child inherits a function merge, whose second argument must be a parent (not a child) and which returns a parent (not a child). Thus the inherited operation loses the homogeneity of the original. Some complications ensue. (For example, the signature of a dispatching variant of merge must mention the parent type, not the child, otherwise it is a different operation.) Because of this asymmetry, it is possible to subvert the dispatching mechanism and to call a dispatching operation with invalid arguments -- and unpredictable results. In contrast, the Ada 9X dispatching model specifies that all dispatching parameters must have the same type (more precisely the same tag). A predefined exception is raised if this condition is violated. We conclude that the Ada 9X model for type extension provides a cleaner definition of binary operations. 4.2. The limits of friendship The notion of friend functions and friend classes is one of the more controversial aspects of C++. Its defenders correctly point out that the built-in privacy of class members that are not explicitly declared public means that it is well-nigh impossible to write efficient code that makes use of two distinct classes A and B: a member function of A will only have access to the private representation of A, and will have to use a procedural interface (with a potentially large execution penalty) to access the private representation of B. This is often unacceptable (the canonical example is vector-matrix multiplication, when each is defined as a separate class, which forces a large number of redundant index checks in the code). By declaring selectively certain functions as friends of a given class, the permission is granted to write code using the private representation from outside of the class. Many consider this mechanism unsafe, and advise against its use. In Ada, the need for such a mechanism is lessened by the possibility of defining related types in the same package. Those types can be private, and yet functions defined in (and exported by) the packaged can make use in their bodies of the private representations of these types. This style respects the interface between interface and implementation, but requires more design discipline (both types must be conceived simultaneously). In Ada 9X, an additional mechanism exists to create related entities in separate units: the hierarchical library model. Child packages can selectively request visibility of the private parts of the parent packages. This mechanism is as expressive as the C++ friend declarations. It is also independent of inheritance. 5. Keeping track of time Ada was the first mainstream language to incorporate constructs for multitasking and for real-time programming. It is still virtually the only language to do so in a coherent fashion. Ada 9X will have much more developed real-time and synchronization facilities, in particular constructs for data synchronization (protected records). There are as yet no winning proposals for tasking facilities in C++, and no hint of notions of real-time and scheduling tools. In this area C++ is a non-starter, even compared with Ada83. And yet C and C++ are used for programming real-time systems. How is this done? By means of libraries in various stages of standardization, such as the CIFO proposed standard. Here again, "it can be done" in C++, if we regard these large libraries as part of the greater C++ system. Needless to say, as long as these are not recognized standards, programs that use them will be non-portable in subtle ways. It may well be that a standard library of real-time primitives will evolve and become part of C++, just as the stream facility has evolved from an interesting user-defined class to a recognized part of the language. In the meantime, Ada 9X has the advantage of features that are integrated from the beginning, with a well-understood interaction between complex features (e.g., tasking and exception). Ada 9X expands on the tasking facilities of Ada with asynchronous transfer of control, protected records, better user access to scheduling primitives, additional forms of delay statements, and parametrized tasks. We conclude that in the area of real-time programming Ada 9X is still without any serious competition. 6. Generics are cheap and reliable To maximize software reuse, it is important to be able to parametrize software components, so that the same blueprint can be used in type-safe fashion for different applications. For example, a single sorting algorithm can be used for arrays of different element types, as long as the element type is ordered (i.e., has a comparison predicate). The generic facility of Ada is an excellent model of type parametrization. In addition to type parameters with specified operations (private and limited generic types) it is possible to specify type parameters that belong to a given class of types (e.g., any integer type), as well as value parameters and object parameters. In contrast, C has no parametrization facilities. The common practice is to use the C preprocessor (a macro expander) to duplicate text with suitable replacement, in order to simulate generic instantiation. This mechanism is purely lexical: there are no syntax or semantic checks attached to the macro definition nor to each of its expansions. The designer of C++ has recognized the need for a more disciplined parametrization mechanism, and the latest version of the language describes templates, a facility that is close in spirit to Ada generics. A template indicates that a unit has one or more class parameters. In the simple case there are no operations defined on a class parameter, so it is equivalent to an Ada private generic type. It is possible to include function parameters that depend on a class parameter; this is equivalent to the use of generic formal subprogram parameters in Ada. There is an asymmetry between class parameters and function parameters which is not present in Ada, and the syntax forces repeated mentions of the template parameters (e.g., for each member function body of a class template). Ada 9X has an even richer set of parametrization mechanisms than Ada. In Ada 9X it is possible to specify generic derived types (where the actual is any member of the class of the generic type) and generic formal packages (where the actual is any instantiation of the generic formal package). This later form of parametrization is more powerful than what is available in C++, and is akin to the use of functions and signatures in ML. Both in terms of expressiveness and clarity Ada 9X has a clear advantage over C++ here. 7. Multiple Inheritance It might be argued that the multiple inheritance model of the current version of C++ is definitely superior to what is proposed for Ada 9X. This is a most minor point: multiple inheritance (MI) is a programming style, not a universal tool, and object-oriented practice of the last 10 years indicates that the critical benefit of OOP, namely code reuse, is not substantially enhanced by multiple inheritance. Without denying that some programming situations benefit from MI, we can state that its presence does not make or break an object-oriented language. Furthermore, the introduction of multiple inheritance complicates the type model, complicates the implementation of dynamic dispatching, and brings semantic difficulties that are solved by the introduction of virtual base classes, a substantial complexity in its own right. A common use of multiple inheritance is to construct "mixins", but in most of the examples we have seen, there is clearly a major and a minor parent; the minor provides additional functionality to a type that is clearly an extension of the major parent. Programming techniques exist to obtain the effect of mixins in Ada 9X, by combining type extensions with renaming: type gizmo is ... procedure fiddle(g: in out giizmo) ; type enhanced is new old_and_reliable with record g: gizmo; end record; ... procedure fiddle(e: in out enhanced) is begin fiddle(e.g) ; end ; This is equivalent to a C++ declaration where enhanced is defined as a class that inherits both from old_and_reliable and from gizmo. It does require a few additional lines of Ada 9X code to obtain the same effect, but does not require a complex additional feature. Finally, a common use of multiple inheritance is to provide visibility. What would be done in Ada by the use of context clauses that name several packages, can be achieved in C++ by inheriting from several classes. Here again, classes play the role of Ada packages rather than that of types. We conclude that by rejecting multiple inheritance Ada 9X loses no significant functionality, and gains in simplicity. 8. Appearance Counts Ada programs read well. This is acknowledged by all who have ever seen Ada code, and it has a profound effect on program maintenance. Readability was one of the guiding criteria in the design of the syntax of Ada, and the design is obviously successful. One might say that Ada reads well because it sounds right. This not to say that Ada programmers move their lips when parsing Ada code, but rather that reading carefully means hearing in one's mind, and it helps if what one hears is pronounceable, in some very general sense. Ada text is dense in keywords, which some mistakenly consider noisy and redundant. In fact, those keywords act as natural punctuation marks, and make program reading more natural: a begin-end bracketing is more natural-sounding than {..}. The syntax of Ada 9X has the same qualities. A few keywords have been added, and others have been put to novel uses (e.g., with in type extensions), but the sound of the language remains. In contrast, C and C++ emphasize ease of writing rather than ease of reading. Thus a greater use of operators, of terser notations (the conditional expression, for example) and an absence of keywords (most noticeably in declarations). This makes C++ programs harder to transmit and to maintain. Thus, seemingly minor considerations of surface syntax can have a profound effect on the economics of using one language or another. The readability of Ada is a substantial money-saver. 8.1. The principle of minimal surprise One of the most striking aspects of the C and C++ communities is the number of language idioms that are part of the programming culture. Idioms are typically short, cryptic expressions with great power (this notion of idiom is most intensely developed in the APL community). The study of idioms has produced such entertaining books as [F82], and it is clear that C and C++ programmers enjoy enormously the game of "guess what this computes?". The question would not be fun if the answer were not in same way unexpected! Thus these languages systematically violate the informal rule of design known as the principle of minimal surprise. In contrast, this form of entertainment is completely missing from the Ada culture. Ada code does what it says, plainly. It is interesting to compare [MB92] with [f82]. A large number of the examples used Mendal and Bryan ask: is the code legal? The Ada programmer may be frustrated when his code is rejected by the compiler, but he is much less likely to be surprised by the behavior of code that compiles without error. 9. Conclusions To compare Ada 9X and C++ is not easy, if for no other reason than C++ is a language in flux for which no stable definition exists, no approved standard reference, and no translator validation suite. A glance at the list of additions to the language since version 2.0 (see [S91]) is sufficient to realize that active language design is still going on. Of course, Ada 9X is in even greater flux, but we know that the standardization mechanisms that were successful from Ada83 will be in place here as well. The ongoing ISO WG9 work (most recently at its meeting in Frankfurt, March 30 to April 3) ensures that Ada 9X will be an international standard within a shorter time frame than C++, and that the standard will have the active approval of all member countries interested in programming languages for software systems. C++ is for now the promise of a good language. It is also a number of related but not identical implementations, that are being used fairly widely in the software industry. If the DoD experience of the last quarter century can be distilled to a single fact, it is that lack of portability and reusability are the most direct causes of runaway software costs. The strong standardization, and the resulting portability of Ada code have proved their worth many times over the past decade. The use of a less well-defined tool would be a large step backwards. This being said, it would disingenuous to deny the current success of C++ in the software community. In our opinion, this success is mostly due to the fact that C++ is much better than C, and for the legions of C programmers this means a language that provides some measure of type checking, which is a large improvement over their previous standards. In addition, the classes of C++ are a convenient tool for data abstraction and information hiding (very much like Ada packages) and programmers are justifiably pleased to use them. Finally, C and C++ benefit from an environment which is mostly written in the same language, so that interface problems are fewer. Although the C++ community would never state it so boldly, it appears clear to us that C++ is to some extent a reaction to Ada. By extending C with some of the best ideas of Ada (strong typing, exceptions, generics) C++ did in some measure catch up to Ada. Ada 9X offers the chance to leapfrog C++, by extending the language in two critical areas: object-oriented programming (with type extensions) and real-time programming (with protected records and flexible scheduling). This comes on top of a language with incomparable type safety, (which should be contrasted with the "user beware" philosophy of C and C++) and a culture that is now 10 years mature and that yields cleaner and safer software than that produced with any other systems programming language. Ada 9X seems well worth the wait. References [AMSR] Intermetrics, Ada 9X Mapping Specification and Rationale, version 4.1 Boston, MA, Intermetrics, March 1992. [F82] Allan R. Feuer, The C Puzzle Book, Englewood Cliffs, NJ, Prentice-Hall, 1982. [H91] Cay S. Horstmann, Mastering C++, New York, Wiley and Sons, 1991. [MB92] Geoffrey O. Mendal and Douglas L. Bryan, Exploring Ada, volumes 1 and 2, Englewood Cliffs, NJ, Prentice-Hall, 1992. [S91] Bjarne Stroustrup, The C++ Programming Language, 2d edition. Reading MA, Addison-Wesley, 1991. ********************** Reprinted with permission. Ada Information Clearinghouse (AdaIC) P.O. Box 46593 Washington, DC 20050-6593 703/685-1477, 800/AdaIC-11, FAX 703/685-7019 adainfo@ajpo.sei.cmu.edu; CompuServe 70312,3303 The AdaIC is sponsored by the Ada Joint Program Office and operated by IIT Research Institute.