This paper compares four computer programming languages (Ada95, C, C++, and Java) with the requirements of "Steelman", the original 1978 requirements document for the Ada computer programming language. This paper provides a view of the capabilities of each of these languages, and should help those trying to understand their technical similarities, differences, and capabilities.
In 1975 the U.S. Department of Defense (DoD) established a "Common High Order Language" program with the goal of establishing a single high order computer programming language appropriate for DoD embedded computer systems. A High Order Language Working Group (HOLWG) was established to formulate the DoD requirements for high order languages, to evaluate existing languages against those requirements, and to implement the minimal set of languages required for DoD use. The requirements were widely distributed for comment throughout the military and civil communities, producing successively more refined versions from Strawman through Woodenman, Tinman, Ironman, and finally Steelman. Steelman was released in June 1978 [DoD 1978]. An electronic version of Steelman is available at "http://www.adahome.com/History/Steelman/intro.htm". The original version of the Ada computer programming language was designed to comply with the Steelman requirements.
Today there are a number of high order languages in commercial and military use, including Ada95, C, C++, and Java. I thought it would be an interesting and enlightening exercise to compare these languages to Steelman; this paper provides the results of this exercise. Other comparisons of these languages do exist (for example, [Sutherland 1996, Seidewitz 1996]), but none use the Steelman requirements as a basis.
This paper compares four computer programming languages (Ada95, C, C++, and Java) with the requirements of "Steelman". The paper first describes the rules used in this comparison of these four languages with Steelman. This is followed by conclusions summarizing how each language compares to Steelman. After the references is a large table, the "meat" of this paper, showing how each of these languages compare to each of the Steelman requirements.
This paper does not attempt to determine if the Steelman requirements are still relevant. In the author's opinion, most of the Steelman requirements are still desirable for general-purpose computer languages when both efficiency and reliability are important concerns. Steelman is no doubt incomplete; in particular, object-orientation is not a Steelman requirement but is widely considered desirable. However, desirability and completeness need not be true for this comparison to be useful, because this paper simply uses Steelman as a framework for examining technical issues of these computer languages. Steelman is a useful framework because it was widely reviewed and is technically detailed.
The primary rule used in this paper is that a language provides a feature if:
Features that are only provided by a single implementation, or are defined but cannot be depended upon across the most commonly used implementations, are not considered to be part of the language. Examples of features that cannot be depended on are features which are often unimplemented, implemented incorrectly on widely-used compilers, or implemented with significantly differing semantics. Subset compilers for research or student work are not considered unless they are widely used by users of that language. One area where some "benefit of the doubt" is given is for C++ templates. C++ templates are part of the C++ language definition, but current C++ compilers implement templates with different semantics [FSF 1995] and with different levels of quality [OMG 1995]. As a result, C++ templates are currently difficult to use in a portable way. Still, credit is given for C++ templates since the intent is clear and they can be used today (with trouble) on most compilers.
The defining documents used for each of these languages are as follows:
The appendix shows how well each language supports each Steelman requirement.
The following table shows the number of Steelman requirements met by each language. The leftmost column shows the name of the language. The next columns are the number of requirements the language does not meet, only partially meets, mostly meets, and completely meets. The final column shows the percentage of Steelman requirements mostly or completely met by the language. Note that Ada meets the most, followed by Java, C++, and C in that order. The Java and C++ percentages are probably too close to be considered significantly different.
| Language | "No" | "Partial" | "Mostly" | "Yes" | Percentage of Answers with "Mostly" or "Yes" |
|---|---|---|---|---|---|
| Ada | 3 | 5 | 11 | 94 | 93% |
| C | 32 | 21 | 16 | 44 | 53% |
| C++ | 19 | 17 | 23 | 54 | 68% |
| Java | 20 | 12 | 22 | 59 | 72% |
Caution is warranted, since differing percentages of "yes" values do not necessarily imply that a particular language is more suitable than another for a given specific task. Note that the original version of Ada was specifically designed to meet the Steelman requirements, while none of the other languages were specifically designed to do so, so it is expected that Ada would meet more of the Steelman requirements than the rest. Also, all of these languages have capabilities that are not Steelman requirements. For example, direct support for object-orientation is a feature of Ada, C++, and Java, but is not a Steelman requirement. Readers should use this comparison to gain additional understanding of each of these different languages, and determine which "yes" and "no" values are of importance to them.
The following are high-level remarks comparing each language to Steelman
based on the table in the appendix, including remarks on the
language support for reliability (requirement 1B):
Again, users of this paper should apply caution; differing percentages
of "yes" values and capabilities do not necessarily
imply that a particular language is more suitable
than another for a given specific task.
Readers should examine each answer and determine which
"yes" and "no" values are of importance to them.
This information is intended to help readers
gain additional understanding of each of these different languages.
** This paper is not endorsed by, and does not necessarily represent the views of, the Institute for Defense Analyses (IDA), the U.S. Department of Defense (DoD), or the U.S. Government.
I am grateful to Michael Kappel, Magnus Kempe, and James Kuehn for their constructive comments.
In this table, the left-hand column gives the Steelman requirement. The next four columns show how well Ada, C, C++, and Java meet this requirement. An entry of "yes" indicates that the language and its major implementations generally meet the requirement, while a "no" indicates that requirement is generally not met. There are two intermediate entries: "partial" indicates some of the requirement is met, but a significant portion (or intent) of the requirement is not met, "mostly" indicates that the requirement is generally met, but some specific capability of the requirement is not fully met. Underneath the columns for each language is commentary explaining these entries.
I have tried to be fair to all of these languages. Nevertheless, some of these entries, particularly in section 1, are judgement calls. Readers are encouraged to revisit each entry (particularly in section 1), compare each language, and draw their own conclusions. Items which I felt are particularly questionable have been marked with a question mark ("?").
| Requirement | Ada | C | C++ | Java | Comments |
|---|---|---|---|---|---|
| 1A. Generality. | yes | yes | yes | partial | Java can't directly control hardware; Java programs must declare native methods and implement such operations in another language. |
| 1B. Reliability. | yes | no | partial? | mostly? | Ada requires separate specifications for all modules other than stand-alone subprograms. C and C++ contain many well-known traps (= vs. ==, & vs. &&, premature semicolon in control structures, fall-through behavior in switch statements when "break" is omitted); some were removed or made less likely in Java but others were not. C permits separate specifications (through prototypes) but are optional; function names are globally accessible by default and can be incorrectly redefined. C++ supports separate specifications and has a slightly tighter type system than C. Also, good use of C++'s object-oriented features should increase the likelihood of compile-time detection of some kinds of errors. Java automatically generates specifications (as opposed to using redundant specifications). C and C++ do little checking at run-time. Both Ada and Java perform a number of run-time checks (e.g. bounds checking and checks for null values) to detect errors early. |
| 1C. Maintainability. | yes? | partial? | partial? | mostly? | Ada was originally designed with readability in mind. C was not, and can easily be (ab)used to make impenetrable code. C (and hence C++ and Java) includes a great deal of terse notation which reduces readability (e.g. the "for" loop notation, using "&&" instead of "and", and operators such as "<<"). C++'s object-oriented features, if used, are likely to improve maintainability (because they force interfaces to be defined and used). Java's document comments (//*) and standard documentation conventions aid in readability. Note that "readability" of a programming language is extremely subjective - well-structured programs can be read and maintained in any language by someone who knows the language, and no language can prevent all poor approaches. At issue in this requirement is how strongly the language encourages readable and maintainable code. |
| 1D. Efficiency. | yes | yes | yes | partial? | Ada functions returning unbounded size objects usually have hidden extra efficiency costs (access types can be used where this is important). C++ implicit conversion operations may be activated in situations not easily recognizable by its users. C/C++ pointer arithmetic and aliasing prohibit some optimizations. Java's garbage collection raises questions about efficiency and guaranteed timing, especially in real-time systems. |
| 1E. Simplicity. | yes | yes | mostly | yes | Ada includes both Ada 83's discriminated records and the newer (OO) tagged types (these have many similarities). C is a very simple language (though not necessarily simple to use). C++ has C operations and its own operations (new/delete vs. malloc/free, cout vs. printf). |
| 1F. Implementability. | yes | yes | yes | yes | All of these languages have been reasonably implemented. |
| 1G. Machine Independence. | yes | yes | yes | yes | Approaches differ. Ada includes a number of mechanisms to query the underlying configuration (such as bit ordering conventions) and C/C++ include some querying mechanisms. Conditional compilation in Ada and Java is handled through "if (constant)" statements (this does not permit conditional compilation in cases where "if" statements are not permitted). Java has few mechanisms for querying the underlying configuration and imposes requirements on bit length and semantics of numeric types that must be supported. Java strives for machine independence by hiding the underlying machine. |
| 1H. Complete Definition. | yes | yes | yes | yes | |
| 2A. Character Set. | yes | mostly (trigraphs and digraphs) | mostly (trigraphs and digraphs) | no | C, C++, and Java usually use a number of characters (such as {, }, [, ], and #) that are not available on some European terminals (which only offer the seven-bit ISO 646 character set and use these positions for accented characters). C added trigraphs to help European users, but trigraphs are horrible to use in practice. Normative Addition 1 to C added digraphs and the <iso646.h> header in an attempt to make C easier to use in such cases; while somewhat improved, such programs are still more difficult to read. Note that supporting restricted character sets is becoming less important as old 7-bit European terminals disappear, and restrictions to support upper-case-only users are now irrelevant. |
| 2B. Grammar. | yes | yes | partial | yes | C has a few cases where parser state dependent feedback to the lexical analyzer is necessary (e.g. typedef, preprocessor tokenization). C++ is more difficult to parse because it isn't LALR(1). Java isn't really LALR(1) either, but known techniques make it so it can be handled as though it is LALR(1). |
| 2C. Syntactic Extensions. | yes | no | no | yes | C/C++ preprocessor can be used to create some (obscure) syntactic forms. A preprocessor (such as cpp or m4) can be used with any language, including Ada and Java, but neither include a preprocessor in their definition. |
| 2D. Other Syntactic Issues. | yes | mostly | mostly | mostly | C comments (also supported by C++) cross multiple lines. C,C++, and Java don't have "closing" key words, but use matching opening and closing braces. Matching braces have the advantage of being easy to type and support with text editors, but permit errors in maintenance when the "wrong" matching braces are used. |
| 2E. Mnemonic Identifiers. | yes | yes | yes | yes | All support this. Note that Ada is case-insensitive, while C, C++, and Java identifiers are case-sensitive. |
| 2F. Reserved Words. | yes | yes | yes | yes | |
| 2G. Numeric Literals. | yes | mostly | mostly | yes | All support numeric literals for integers. C and C++ permit implicit rounding, though many compilers will catch this. Only Ada directly supports fixed point numbers (see 3-1G). |
| 2H. String Literals. | yes | yes | yes | mostly | Java String and String_Buffer are considered special types, not one-dimensional character arrays. |
| 2I. Comments. | yes | no | yes | yes | Only C lacks comments automatically terminated by the end of line. Note that in practice, many C compilers share the preprocessor with C++ and can permit //-style comments with special compilation options, but this is not permitted portably by the C standard. |
| 3A. Strong Typing. | yes | partial | mostly | yes | Note that C and C++ have compile-time types but both are more weakly typed. Typedef does not define a new type, just a name synonym. A pointer to an array of objects is considered equivalent to a pointer to an object. In C, enumerations are considered identical to int, while in C++ enumerations are different types. |
| 3B. Type Conversions. | yes | no | partial? | partial? | C, C++, and Java do not have subtypes (types with additional constraints) for primitive types (such as int or float). Class structures can be used in C++ and Java to implement additional constraints on classes. C and C++ have some representation control using bitfield locations; this is not considered separate from the type. C and C++ have a number of implicit conversions. |
| 3C. Type Definitions. | yes | mostly | mostly | mostly | C and C++ don't have subtypes. Java doesn't have subtypes or enumerated types; see 3B and 3-2A. |
| 3D. Subtype Constraints. | mostly | no | no | no | Ada supports user definition of range, precision, scale, and index ranges, but does not directly support arbitrary user-defined constraints. With effort constructors and operations in C++ and Java could be used to enforce constraints. |
| 3-1A. Numeric Values. | yes | partial? | partial? | partial? | All support integers and floats. C, C++, and Java don't raise exceptions on integer overflow. C/C++ implementations often define ways to handle IEEE floating point exceptions. Java does throw an exception for division by zero. The question marks are noted because it's not clear how much a penalty should be assessed for this. |
| 3-1B. Numeric Operations. | yes | mostly | mostly | mostly | In C, C++, and Java the exponentiation operator is pow(), not the usual infix operator, and the built-in operation only takes arguments of type double (not int). C provides an absolute value function for int but not double. |
| 3-1C. Numeric Variables. | yes | yes | yes | yes | Counting built-in types (such as "Integer" or "int") as specifying a range, all of these languages do so to some extent. C, C++ and Java do not support user-defined numeric ranges (see 3D). |
| 3-1D. Precision. | yes | partial | partial | mostly | The standards for C and C++ define the minimum precision of double and float, but no control over actual precision. Java defines specific precisions for double and float, and no other control over precision. |
| 3-1E. Approximate Arithmetic Implementation. | yes | yes | yes | no | Ada makes the precision, radix, and exponent range available through language-defined attributes. C and C++ make these available through <float.h>. Java defines these in the language itself. Java requires IEEE arithmetic semantics (with specific options) to be used, regardless of the underlying machine's floating point mechanisms. |
| 3-1F. Integer and Fixed Point Numbers. | yes | partial | partial | mostly | C, C++, and Java don't support fixed point numbers. C++ and Java classes could be used to build fixed point functionality. C and C++ permit implicit truncation in integer computations. |
| 3-1G. Fixed Point Scale. | yes | no | no | no | No built-in fixed point support in C, C++, or Java. |
| 3-1H. Integer and Fixed Point Operations. | yes | no | no | no | All support "modulo" operators; C, C++, and Java don't support fixed point numbers. |
| 3-2A. Enumeration Type Definitions. | yes | mostly | mostly | no | Java doesn't support enumerations. C enumerations are weakly typed (integers can be freely assigned to them); C++ tightens this slightly (but still permits quiet conversions from enum to int). C and C++ only permit identifiers (not character constants) as enumeration elements. Neither C nor C++ support sub-sequences. |
| 3-2B. Operations on Enumeration Types. | yes | mostly? | mostly? | no | C and C++ don't have operations to determine the first and last enumerated value. |
| 3-2C. Boolean Type. | yes | no | yes | yes | C doesn't have a "bool" type; C++'s bool type is weakly typed. Both Ada's and Java's boolean type is fully distinct from their integer types. |
| 3-2D. Character Types. | yes | yes | yes | partial | All languages have a predefined character type, though it's not necessarily considered an enumerated type. C and C++ enumeration types can be used to create "character sets", though this is rarely done. Java lacks enumeration types. |
| 3-3A. Composite Type Definitions. | yes | yes | yes | yes | All have arrays and records (Java and C++ classes may be used as records). |
| 3-3B. Component Specifications. | yes | yes | yes | yes | Range, precision, and scale specifications are included in numeric type definitions (with support varying, see 3-1). |
| 3-3C. Operations on Composite Types. | yes | yes | yes | yes | The "constructor" meant here is simply the ability to declare or allocate a value of the given type, which all support. Ada, C++, and Java provide more sophisticated control over construction. |
| 3-3D. Array Specifications. | yes | mostly | mostly | mostly | C, C++, and Java array indexes may only start at zero and cannot use enumerations to define array subscripts. In C enumerations may be used to access array elements. In C++ enumerations can be cast into int's to access array values, while Java has no enumeration types. |
| 3-3E. Operations on Subarrays. | yes | no | no | no | C and C++'s memcpy and memcmp can be used to do some of these operations using an extremely low-level interface. C, C++, and Java do not have array concatenation operators (Java has a string concatenator as a special case). |
| 3-3F. Nonassignable Record Components. | no | no | yes | yes | C++ and Java classes can include constants (and functions). |
| 3-3G. Variants. | yes | yes | yes | yes | Java and C++ class structures can be used to simulate at run time the typical uses of variants. C and C++ also permit "unions" to define types with alternative record structures without tag fields. |
| 3-3H. Tag Fields. | yes | no | yes | yes | Java operations (e.g. instanceof) and C++ RTTI can be used to simulate typical uses of tag fields. Note that C unions do not have automatic tag fields. |
| 3-3I. Indirect Types. | yes | yes | yes | yes | Ada access values, C/C++ pointers, and Java object references support this. Note that Java requires garbage collection and Ada permits garbage collection as an option (with a pragma for controlling it). C/C++ implementations usually do not include garbage collection, although conservative garbage collection systems for C/C++ are available. C and C++ permit pointers which reference deallocated storage. Ada programs using Unchecked_Deallocation may reference deallocated storage. |
| 3-3J. Operations on Indirect Types. | yes | yes | yes | mostly | Note that the "constructor" mentioned here is "new" (in Ada, C++, and Java) or "malloc" (in C or C++). Note that Ada, C++, and Java (but not C) provide additional control over constructors. Copying isn't defined automatically in Java. |
| 3-4A. Bit Strings (i.e., Set Types). | yes | partial? | yes | yes | In Ada, declare a packed array of boolean values. In C, short bit strings can be handled using "int" or "long", but longer bit strings are best handled through user-defined functions or macros. In C++, use the STL template class bitset (for short ones, use bitmask). In Java, use class BitSet in package "java.util". |
| 3-4B. Bit String Operations. | yes | partial? | yes | mostly | In C, such operations can be easily created with the built-in operations when there are sizeof(long) or fewer bits; longer bit strings are typically handled by user-defined functions or macros. Java BitSet doesn't have a group negation ("not") operation. |
| 3-5A. Encapsulated Definitions. | yes | yes | yes | yes | Ada's unit of encapsulation is the package. C's is the ".h" file. C++'s are classes and ".h" files. Java's is the class. |
| 3-5B. Effect of Encapsulation. | yes | partial | yes | yes | C encapsulation requires extreme discipline using the "static" keyword (the default is to make everything globally accessible). C++ more strongly supports encapsulation when classes and the private modifier are used. |
| 3-5C. Own Variables. | yes | yes | yes | yes | |
| 4A. Form of Expressions. | yes | yes | yes | yes | |
| 4B. Type of Expressions. | yes | yes | yes | yes | Ada qualifiers do this. C, C++, and Java "casts" can do this, but may also quietly invoke a conversion operation. |
| 4C. Side Effects. | mostly | partial | mostly | mostly | All permit side effects beyond their own variables of encapsulation (e.g. global variables or other objects can be affected). C encourages this, and combined with macros can cause unexpected results (e.g. "putchar(*p++)"). Such use is not necessarily considered erroneous in C/C++. C++ permits the same effects, though due to other language features (such as OO features) they tend to receive less use. |
| 4D. Allowed Usage. | yes | yes | yes | yes | |
| 4E. Translation Time Expressions. | yes | yes | yes | yes | C, C++, and Java specifications do not require all literals to be evaluated at compile time, but compilers typically do so. |
| 4F. Operator Precedence Levels. | yes | mostly | mostly | mostly | C, C++, and Java have a large number of precedence levels. |
| 4G. Effect of Parentheses. | yes | yes | yes | yes | |
| 5A. Declarations of Constants. | yes | yes | yes | yes | |
| 5B. Declarations of Variables. | yes | mostly | mostly | yes | C and C++ permit "void *" as a type, which is really a pointer to an unknown type and subverts the type system. |
| 5C. Scope of Declarations. | yes | partial | mostly | mostly | All support nested scopes of variable declarations. Ada supports hierarchical packages, nested packages, and nested subprograms. C only provides two scope levels for functions: static and non-static. Java and C++ support class scoping mechanisms (private, protected, and public) and larger structuring mechanisms (C++ namespaces and Java nested packages). Neither Java nor C++ support nested functions (functions declared in other functions). |
| 5D. Restrictions on Values. | no | no | no | no | Ada, C, and C++ support the use of access/pointer to subprograms/functions. The original Ada83 did not permit access to subprograms; this was later found to be too limiting. Ada and C++ permit passing of exceptions as values. Java does not support pointers to functions, though Java interfaces can be used as a somewhat clumsy workaround. Java permits types and exceptions to be assigned and used as nongeneric parameters. |
| 5E. Initial Values. | partial | yes | yes | partial | Ada defines an initial value for access values. Java defines initial values for all types, though recommends against using them and Java compilers attempt to warn of such use. In both Java and Ada, this is to support reliability. |
| 5F. Operations on Variables. | yes | yes | yes | yes | |
| 5G. Scope of Variables. | yes | yes | yes | yes | The languages differ significantly in their notions of "importing" and how scoping is handled, but all support the essence of this requirement. |
| 6A. Basic Control Facility. | yes | yes | yes | yes | C, C++, and Java have both "continue" and "break" operations, which could be viewed as two "exit" points from a control structure. Java has a multi-level break statement, but these goes to specific exit points in specific control structures. |
| 6B. Sequential Control. | yes | yes | yes | yes | All use statement terminators. |
| 6C. Conditional Control. | yes | yes | yes | yes | |
| 6D. Short Circuit Evaluation. | yes | yes | yes | yes | |
| 6E. Iterative Control. | yes | mostly | mostly | mostly | In C, C++, and Java, the loop control variable is not considered a constant. |
| 6G. Explicit Control Transfer. | yes | yes | yes | partial | The Java language does not include the "goto" (though it does reserve the keyword). Java does have a multi-level break and continue statement which can serve the role of "goto" in many cases. K&R does not list any restrictions on C's goto statement, so some implementations may permit entry into control structures. |
| 7A. Function and Procedure Definitions. | yes | no | yes | yes | C does not permit multiple functions to share the same name even when the parameter signatures differ. |
| 7B. Recursion. | yes | yes | yes | yes | |
| 7C. Scope Rules. | yes | yes | yes | yes | |
| 7D. Function Declarations. | mostly | mostly | mostly | mostly | Ada permits any type as a function return value, and does not require the number of components to be determined by function call time (which gives flexibility at the cost of efficiency when using this capability). Java also permits a function to return an array without knowning the number of components at call time; Java's approach to arrays is different than that implied by this requirement. |
| 7F. Formal Parameter Classes. | yes | partial | partial | no | C, C++, and Java do not identify in, out, and in-out parameters. C and C++ can identify in-only parameters using "const" or by using non-pointer types. C++ supports passing by reference as well as passing by value (which implies that the item already exists). |
| 7G. Parameter Specifications. | yes | mostly | mostly | yes | C and C++ permit re-specification in other places, permitting the specifications to go "out of sync". C and C++ also permit recasting of pointers that can subvert the type specification. |
| 7H. Formal Array Parameters. | yes | no | no | partial? | Subscript ranges are not accessible in C and C++. C, C++, and Java don't support multidimension arrays, though arrays of arrays permit some similar operations (particularly in Java). |
| 7I. Restrictions to Prevent Aliasing. | yes | no | no | no | Aliasing is a well-known problem when trying to optimize C and C++ code. Java defines all non-primitives as references and does not permit "internal" references, so in some sense all aliases are intended. |
| 8A. Low Level Input-Output. | mostly? | partial | partial | no | Ada, C, and C++ permit access to memory-mapped locations but do not have standard I/O channel operations. Ada's machine code insertion capability can perform I/O channel operations in the language. |
| 8B. User Level Input-Output. | yes | yes | yes | yes | Ada and Java applets may be restricted further by the environment, but this is determined by the local applet security manager and user, not by the language. |
| 8C. Input Restrictions. | yes | yes | yes | yes | |
| 8D. Operating System Independence. | yes | yes | yes | yes | |
| 8E. Resource Control. | mostly | no | partial | partial | Ada supports memory storage pool management (managed by the allocation/deallocation language features), task scheduling policies, and task priorities. The C++ "new" operator can be overridden to support memory storage pool management. Java supports thread priorities. |
| 8F. Formating. | yes | partial | partial | partial | C and C++ don't have built-in enumeration reading and writing; Java doesn't have enumerated types. |
| 9A. Parallel Processing. | yes | no | no | yes | C and C++ do not have have built-in thread or process facilities - the assumption is that these are to be provided by operating system dependent libraries (such as the POSIX p-threads library). Java's parallel processing facilities differ in approach from the wording of this requirement, but can provide these facilities. |
| 9B. Parallel Process Implementation. | mostly | no | no | mostly | Both Ada and Java leave some semantics open to permit efficient implementation on different operating systems. |
| 9C. Shared Variables and Mutual Exclusion. | partial | no | no | partial | Neither Ada nor Java require shared variables to be marked with an attendant warning. Ada 83's obsolete pragma shared doesn't really meet this requirement. Both Ada and Java support shared variables and high-efficiency locking (using protected types/synchronized guards), and both permit the circumventing of such if the programmer determines it to be necessary. Ada, C, and C++ support marking variables as "volatile", and Ada supports marking variables as "atomic". |
| 9D. Scheduling. | yes | no | no | mostly | Java in general runs the highest priority thread, but permits occasional running of lower priority threads (see "http://java.sun.com/Series/Tutorial/java/threads/priority.html"). Java does not guarantee first-in first-out within a priority. |
| 9E. Real Time. | yes | no | no | yes | C/C++ provide some functions for handling local and calendar time; real-time calls are operating system dependent. Java supports delays in centiseconds and clock access in milliseconds. |
| 9G. Asynchronous Termination. | partial | no | no | yes | C/C++ programs can call an OS-dependent library to perform this task. Ada and Java permit asynchronous termination (via the abort statement and stop() call respectively). Ada does not permit statement sequences to be run on termination in general (though asynchronous transfer of control and the terminate alternative can permit this in some cases). Java can do this by catching Error ThreadDeath. |
| 9H. Passing Data. | yes | no | no | yes | Ada rendezvous and Java synchronized calls permit controlled passing of data. |
| 9I. Signalling. | mostly | no | no | mostly | Java objects can be used as synchronized guards. Ada does not have a "signal" type, but protected types can trivially implement them (see Ada LRM D.12 for an example). C and C++ have a file "signal.h" but this file does not provide this functionality. |
| 9J. Waiting. | mostly | no | no | mostly? | Ada select statement supports such capabilities. Java does not have an equivalent structure, but intermediate structures could be used to easily implement such functionality. |
| 10A. Exception Handling Facility. | yes | no | yes | yes | C's "signal.h" and setjmp/longjmp can be used to handle some exceptions, but don't really satisfy these requirements. |
| 10B. Error Situations. | mostly | partial | partial | mostly | None normally detect uninitialized variables access. Ada's Normalize_Scalars pragma aids in detecting uninitialized variables. Java attempts to detect uninitialized variables at compile-time. Ada and Java don't have assertions built into the language, while C and C++ can detect assertion errors. C and C++ don't detect out-of-bound array accesses. C, C++, and Java don't detect range errors (of either kind) nor overflow. All can detect out-of-memory errors. |
| 10C. Raising Exceptions. | yes | no | yes | yes | C has an assert macro, but it doesn't have the kind of enclosure described here. |
| 10D. Exception Handling. | yes | no | yes | yes | |
| 10E. Order of Exceptions. | yes | no | yes | yes | |
| 10F. Assertions. | no, not built-in | mostly | mostly | no, not built-in | C and C++ include a simple assert() facility. Neither Ada nor Java have a built-in assert checking facility, though they can be trivially implemented. GNAT Ada compiler has pragma assert, but this is compiler-specific. None permit simple assertions of frequency. |
| 10G. Suppressing Exceptions. | yes | no | no | no | |
| 11A. Data Representation. | yes | partial | partial | no | C and C++ bitfields provide some data representation control, but don't control big-endian/little-endianness. Lack of endianness control makes control over portable representation of lower-level constructs very difficult. C and C++ also don't provide mechanisms to control the exact bit size of basic types, nor hooks to interrupts. Java does not provide representation control. |
| 11C. Translation Time Facilities. | partial | partial | partial | no | Ada, C, and C++ all provide some mechanisms to query the compilation environment, though not to the extent given in this requirement. |
| 11D. Object System Configuration. | partial | no | no | no? | Ada requires that separately compiled modules be compatible when linked together, implying some of the requirements here. Java is designed to make this generally unnecessary, by translating to system-independent bytecodes first, so it's arguable if this requirement applies to Java. |
| 11E. Interface to Other Languages. | yes | partial | yes | partial | Ada has standard interfaces to C, Fortran, COBOL, and machine language, and standard pragmas Import, Export, and Convention for interfacing to other languages. Some C implementations support the "asm" keyword. C has little support for interfacing to other languages, but on many systems it is the "standard" host language and serves as a common interface standard for other languages. C++ has a general external linkage system using extern "language", though often only C is supported as the external language. Java has an external link to C. |
| 11F. Optimization. | yes | partial? | partial? | no? | Ada programs can specify whether to optimize for speed or space. C and C++ code cannot make such specifications, but do provide the "register" keyword to provide optimization hints. Most compilers support external optimization flags. |
| 12A. Library. | yes | yes | yes | yes | All provide mechanisms to make reusable components available to a library. |
| 12B. Separately Translated Units. | yes | partial | mostly | yes | All support separate compilation. C separately compiled units need not agree on their interface. This is true for C++ as well, but C++ programs using classes and header files in normal ways obtain most such protection. |
| 12D. Generic Definitions. | yes | no | mostly | no | Ada types cannot be directly made generic, but can be generic via encapsulation. C/C++'s #define preprocessor is not sufficiently powerful to meet these requirements. C++'s templates provide this capability, though weaknesses and different semantics render C++ templates less useful at this time. Java lacks this ability. |
| 13A. Defining Documents. | yes | mostly | mostly | yes | The C and C++ defining documents include a very large number of undefined results. |
| 13B. Standards. | yes | yes | partial | no | Official standards are available for Ada and C. There is no official C++ standard, but work to develop one is ongoing. Work to standardize Java is at an extremely early stage. |
| 13C. Completeness of Implementations. | mostly? | yes in practice | mostly? | yes | Some Ada compilers have not completed their transition to Ada95; the Ada validation process (including the ACVC test suite) helps to ensure that Ada compilers implement the entire Ada language. C implementations need not implement the entire language, but production compilers generally do so. Since the definition of C++ is changing, C++ compilers are mostly complete as of some version of the C++ standard. Note that all compilers have bugs, so none can truly process "any" correct program. |
| 13D. Translator Diagnostics. | yes | partial | partial? | yes | All provide at least some error reporting and warnings, all have optimizing compilers, and all permit separate compilation. Translator characteristics for detecting errors in the presence of separate compilation are undefined by C and C++. Shared definitions are not required in C; they are generally used in C++. Many C compilers do not do full type checking; lint (where available) can supplement checking. |
| 13E. Translator Characteristics. | mostly | mostly | mostly | mostly | Many compilers are implemented in their own language, though not all. Java implementations may have two code production stages, one that generates virtual machine code and a second that converts virtual machine code to a specific machine's code. |
| 13F. Restrictions on Translators. | yes | partial | yes | yes | The C language definition still permits externally-visible identifiers to be considered identical if the first 6 characters are equal ignoring case (as a concession to old linkers). C++ recommends large maximums (see "Implementation Quantities"), though these are not mandated. Credit is given if the limits are sufficiently large that encountering them is very unlikely. |
| 13G. Software Tools and Application Packages. | yes | yes | yes | yes | Many tools exist for all of these languages (particularly for C and C++) from a wide variety of vendors. |
You may Return to the Steelman On-Line Introduction.
(C) 1996 David A. Wheeler.
This paper is not endorsed by, and does not necessarily represent the views of, the Institute for Defense Analyses (IDA), the U.S. Department of Defense (DoD), or the U.S. Government.