Contents - Cultural View

Comparison of Java and C++ 89
• Due to its unconstrained expressiveness, low level C++ language features (e.g. unchecked array access, raw
pointers, type punning) cannot be reliably checked at compile-time or without overhead at run-time. Related
programming errors can lead to low-level buffer overflows and segmentation faults. The Standard Template
Library provides higher-level abstractions (like vector, list and map) to help avoid such errors. In Java, low level
errors either cannot occur or are detected by the JVM and reported to the application in the form of an exception.
• The Java language requires specific behavior in the case of an out-of-bounds array access, which generally
requires bounds checking of array accesses. This eliminates a possible source of instability but usually at the cost
of slowing down execution. In some cases, compiler analysis can prove a bounds check unnecessary and
eliminate it. C++ has no required behavior for out-of-bounds access of native arrays, thus requiring no bounds
checking for native arrays. C++ standard library collections like std::vector, however, offer optional bounds
checking. In summary, Java arrays are "always safe; severely constrained; always have overhead" while C++
native arrays "have optional overhead; are completely unconstrained; are potentially unsafe."
Templates vs. Generics
Both C++ and Java provide facilities for generic programming, templates and generics, respectively. Although they
were created to solve similar kinds of problems, and have similar syntax, they are actually quite different.
C++ Templates Java Generics
Classes and functions can be templated. Classes and methods can be genericized.
Parameters can be any type or integral value. Parameters can only be reference types (not primitive types).
Separate copies of the class or function are likely to be generated for each type
parameter when compiled.
One version of the class or function is compiled, works for all
type parameters.
Objects of a class with different type parameters are different types at run time. Type parameters are erased when compiled; objects of a class
Implementation source code of the templated class or function must be included
in order to use it (declaration insufficient).
Templates can be specialized -- a separate implementation could be provided for
a particular template parameter.
Template parameters can have default arguments (only for template classes, not
functions).
Does not support wildcards. Instead, return types are often available as nested
typedefs.
Does not directly support bounding of type parameters, but metaprogramming
provides this [6]
with different type parameters are the same type at run time.
Signature of the class or function from a compiled class file is
sufficient to use it.
Generics cannot be specialized.
Generic type parameters cannot have default arguments.
Supports wildcard as type parameter if it is only used once.
Supports bounding of type parameters with "extends" and
"super" for upper and lower bounds, respectively; allows
enforcement of relationships between type parameters.
Allows instantiation of class of type parameter type. Does not allow instantiation of class of type parameter type
(except through reflection).
Type parameter of templated class can be used for static methods and variables. Type parameter of templated class cannot be used for static
methods and variables.
Static variables are not shared between classes of different type parameters. Static variables are shared between instances of a classes of
Templated classes and functions do not enforce type relations for type parameters
in their declaration. Use of a wrong type parameter results in the template code
"not working", usually generating an error message at a place in the template
code where an operation is not allowed for that type and not in the user's code.
Proper use of templated classes and functions is dependent on proper
documentation. Metaprogramming provides these features at the cost of
additional effort.
different type parameters.
Generic classes and functions can enforce type relationships for
type parameters in their declaration. Use of a wrong type
parameter results in a type error at the code that uses it.
Operations on parametrized types in generic code are only
allowed in ways that can be guaranteed to be safe by the
declaration. This results in greater type safety at the cost of
flexibility.