High Voltage Shareware/high1.zip/high1/DIR9/A9X_0610.ZIP/9X&CPLUS.HLP

Text File | 1993-06-10 | 29KB | 507 lines

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
                           [e-mail]

                               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 [phone]
           [e-mail]; CompuServe 70312,3303

The AdaIC is sponsored by the Ada Joint Program Office and operated by IIT
Research Institute.