|
Unix Programming - Language Evaluations - C++
C++
When C++ was first released to the world in the mid-1980s
object-oriented (OO) languages were being widely touted
as the silver bullet for the software-complexity problem. C++'s OO
features appeared to be an overwhelming advantage over the ancestral
C, and partisans expected that it would rapidly make the older
language obsolete.
This has not happened. Part of the fault can be laid to problems
in C++ itself; the requirement that it be backward-compatible with C
forced a great many compromises on the design. Among other things,
that requirement prevented C++ from going to fully automatic
dynamic-memory management and addressing C's most serious problem.
Later, feature arms races between different compiler implementers,
unconstrained by a weak and premature standardization effort, pushed
C++ to become rather baroque and excessively complicated.
Another part of the fault must be laid to the failure of
OO itself
to live up to expectations. We examined this problem in Chapter4, observing the tendency of OO methods to
lead to thick glue layers and maintenance problems. Today
(2003), inspection of open-source archives (in which choice of
language reflects developers' judgments rather than corporate
mandates) reveals that C++ usage is still heavily concentrated in GUIs,
multimedia toolkits and games (the major success areas for OO
design), and little used elsewhere.
It may be that C++'s realization of OO is particularly problem-prone. There
is some evidence that C++ programs have higher life-cycle costs than
equivalents in C, FORTRAN, or Ada. Whether this is a problem with
OO or
specifically with C++ or both remains unclear, though there is reason
to suspect both are implicated [Hatton98].
In recent years, C++ has incorporated some important non-OO
ideas. It has exceptions similar to those in
Lisp; that is,
it is possible to throw an object or value up the call stack until it
is caught by a handler. STL (Standard Template Library) provides
generic programming; that is, it is possible to code algorithms that
are independent of the type signature of their data and have them
compiled to do the right thing at runtime. (Only languages that do
compile-time static type-checking need this; more dynamic languages
simply pass around typeless references and support type identification
at runtime.)
Efficient compiled language; upward-compatible with C;
object-oriented platform; vehicle for cutting-edge techniques like STL
and generics — C++ tries to be all things to all people, but the cost
is more complexity than the mind of any individual programmer can
handle. As we noted in Chapter4, the language's principal designer has
conceded that he doesn't expect any one programmer to grasp it
all. Unix hackers do not react well to this; one anonymous but famous
characterization is “C++: an octopus made by nailing extra legs
onto a dog”.
When all is said and done, however, C++'s most fundamental
problem is that it is basically just another conventional language. It
confines the memory-management problem better than it did before the
invention of the Standard Template Library, and a lot better than C
does, but the confinement is brittle; it breaks unless your code
uses objects and only objects. For many types of application its
OO
features are not significant, and simply add complexity to C without
yielding much advantage. Open-source C++ compilers are available; if
C++ were unequivocally superior to C it would now dominate.
Summing up: C++'s best side is its combination of compiled
efficiency with facilities for OO and generic programming. Its worst
side is that it is baroque and complex, and tends to encourage
over-complex designs.
Consider using C++ if an existing C++ toolkit or service library
offers powerful leverage for your application, or if you're in one of
the application areas mentioned above for which an
OO
language is known to be a large win.
The classic C++ reference is Stroustrup's The C++
Programming Language [Stroustrup]. You will find an excellent
beginner's tutorial on C++ and basic OO methods in C++:
A Dialog [Heller].
C++ Annotations [Brokken] is a condensed introduction to C++
for expert C programmers.
The Gnu Compiler Collection includes a C++ compiler. The language
is therefore universally available on Unix and on
Microsoft operating systems; comments made under C
above also apply here. Strong collections of open-source support libraries are available.
However, portability is compromised by the fact that (as of
mid-2003) actual C++ implementations implement widely varying subsets of the
draft ISO standard now in preparation.[125]
C++ Case Study: The Qt Toolkit
The Qt interface toolkit is one of the notable C++ success
stories in today's open-source world. It provides a widget set and API
for writing graphical user interfaces under X, one deliberately (and
rather effectively) designed to emulate the visual look and feel of
Motif, MacOS Platinum, or the Microsoft
Windows interface. Qt actually provides more
than just GUI services; it also provides a portable application layer,
with classes for XML, file access, sockets, threads, timers, time/date
handling, database access, various abstract data types, and
Unicode.
The Qt toolkit is a critical and visible component of the KDE
project, the senior of the open-source world's two efforts to
produce a competitive GUI and integrated set of desktop
productivity tools.
Qt's C++ implementation exhibits the strengths of an
OO
language for encapsulating user-interface components. In a language
supporting objects, a visual hierarchy of interface widgets can be
cleanly expressed in the code by a hierarchy of class instances. While
this sort of thing can be simulated in C with explicit indirection through
hand-rolled method tables, such code is much cleaner in C++.
Comparison with the notoriously baroque C API of Motif is
instructive.
The Qt source code and reference documentation are available at the
Trolltech site.
[an error occurred while processing this directive]
|
