Author : Ian Joyner
Page : 1 Next >>
A Critique of C++
2nd Edition
Ian Joyner
c/- Unisys - ACUS
115 Wicks Rd, North Ryde
Australia 2113
Tel: +61-2-390 1328 Fax +61-2-390-1391
ian@syacus.acus.oz.au
(C) Ian Joyner 1992
Introduction..........................................................1
The Role of a Programming Language....................................2
Safety and Courtesy Concerns........................................6
C++ Specific Criticisms...............................................7
Virtual Functions...................................................7
Pure Virtual Functions.............................................11
The Nature of Inheritance..........................................12
Function Overloading...............................................13
Virtual Classes....................................................15
Name overloading...................................................15
Polymorphism and Inheritance.......................................17
'.' and '->'......................................................18
Anonymous parameters in Class Definitions..........................19
Nameless Constructors..............................................20
Constructors and Temporaries.......................................20
Optional Parameters................................................21
Bad deletions......................................................22
Local entity declarations..........................................22
Members............................................................23
Friends............................................................23
Static.............................................................24
Union..............................................................25
Nested Classes.....................................................25
Global Environments................................................26
Header Files.......................................................27
Class Interfaces...................................................28
Class header declarations..........................................28
Garbage Collection.................................................29
Type-safe linkage..................................................30
C++ and the software lifecycle.....................................31
Reusability and Communication......................................32
Reusability and Trust..............................................33
Reusability and Compatibility......................................33
Reusability and Portability........................................34
Idiomatic Programming..............................................34
Concurrent Programming.............................................34
The role of Language.................................................35
On Writing...........................................................38
Generic C criticisms.................................................39
Pointers...........................................................40
Arrays.............................................................41
Function Parameters................................................42
void *.............................................................43
void fn ().........................................................43
fn ()..............................................................44
Metadata in Strings................................................46
++, --.............................................................46
Defines............................................................48
NULL vs 0..........................................................48
Case Distinction...................................................48
Assignment Operator................................................50
Type Casting.......................................................50
Semicolons.........................................................52
Conclusions..........................................................53
Bibliography.........................................................56
The C++ programming language is becoming widely used. So it is
important and timely to question its success. Two books are already
published on the subject [Sakkinen 92] and [Yoshida 92]. This critique
addresses the following questions. How well does C++ implement
object-oriented concepts? Can it easily implement small, quick projects?
Does it scale up well for large projects? Does it support or hinder good
programming practices? As a result, does it ease the production of
quality software? What is the relationship between a language, compiler
and software developers; and between the language, compiler and the
target system? This last question addresses issues of correctness,
compatibility, portability, and efficiency.
A paper on the recommended practices for use in C++ [Ellemtel 92]
suggests "C++ is a difficult language in which there may be a very fine
line between a feature and a bug. This places a large responsibility
upon the programmer." Is this a responsibility or a costly burden? The
'fine line' is a result of poor language definition. The C++
standardisation committee warns "C++ is already too large and
complicated for our taste" [X3J16 92].
While it is true that C++ is immediately usable by many C
programmers, and many see this as a strength, the C base is C++'s
greatest weakness. This is the engineering compromise that C++ devotees
talk about. Adoption of C++ does not suddenly transform C programmers
into object-oriented programmers. A complete change of thinking is
required, and C++ actually makes this difficult. A critique of C++
cannot be separated from criticism of the C base language, as it is
essential for the C++ programmer to be fluent in C. Many of C's
problems affect the way that object-orientation is implemented and used
in C++. This critique is not exhaustive of the weaknesses of C++, but
it illustrates the practical consequences of these weaknesses with
respect to the timely and economic production of quality software.
This critique criticises C++ in its own right, without comparison to
other languages. Section 2 considers the role of a programming
language. Section 3 examines some specific aspects of C++. Section 4
examines the general role of language. Section 5 is a short comment on
writing. Section 6 looks specifically at C. The conclusion examines
where C++ has left us, and considers the future. The approach taken is
to criticise specific aspects of C++ and C. Each section tries to be
self contained. It is expected that not everyone will agree with all of
the sections. It is probably best to approach the paper, not by reading
it entirely, but to read those sections that interest you. One section,
however, is fundamental to the criticism of C++, that on virtual
functions. This is also the most difficult to understand and technical
section of the paper, but it is fundamental to the understanding of the
weaknesses of C++.
Having said that, I hope that you find this critique useful, and
enjoyable. If by any chance you do, please feel free to distribute it
to your management, peers and friends.
A programming language functions at many different levels and has
many roles. It should be critiqued with respect to those levels and
roles. Historically, programming languages had a very limited role,
that of writing executable programs. As programs have grown in
complexity, this role alone has proved insufficient. Many design and
analysis techniques have arisen to support other necessary roles. The
organisation of projects also required tools external to the language
and compiler, like 'make.' Object-oriented techniques have arisen to
help in the analysis and design phases, and object- oriented languages
to support the implementation phase of OO. Traditional, tried and
tested but failed software practices are infiltrating the
object-oriented world. Object-orientation, however, offers a better
rational approach to software development. The complementary roles of
analysis, design, implementation and project organisation should be
better integrated in the object-oriented scheme. This results in
economical software production.
C++ is an interesting experiment in adapting the advantages of
object-orientation to a traditional programming language. Bjarne
Stroustrup is to be applauded for having the insight to put the two
technologies together. C++, however, retains the problems of the old
order of software production. C++ has an advantage over C as it
supports many facets of object-orientation. These can be used for
limited analysis and design. The processes of analysis, design, and
organisation, however, are still largely external to C++. Thus C++ has
not realised the important advantages of object-orientation that will
indeed lead to the economic production of software.
A language should not only be critiqued from a technical point of
view, considering its syntactic and semantic features. It should also
be critiqued from the viewpoint of its contribution to the entire
software development process. It should enable communication between
project members acting at different levels, from management, who have a
requirement for the product, to testers, who must test the result. It
should also enable communication between project members separated in
space and time. Often one programmer is not responsible for a task over
its entire lifetime.
The primary purpose of any language is communication. A programming
language should support the exchange of ideas, intentions, and decisions
between project members. A programming language should provide a
formal, yet readable, notation to support consistent descriptions of
systems that satisfy the requirements of diverse problems. A language
should also provide methods for automated project tracking. This
ensures that modules (classes and functionality) that satisfy project
requirements are completed in a timely and economic fashion. A
programming language aids reasoning about the design, implementation,
extension, correction, and optimisation of a system.
A language definition should enable the development of integrated
automated tools to support software development. For example, browsers,
editors and debuggers. The compiler is another such tool. The role of
a compiler is twofold. Firstly, to generate code for the target
machine. The role of the machine is to execute the produced programs.
A compiler has to check that a program conforms to the language syntax
and grammar, so it can 'understand' the program in order to translate it
into an executable form. Secondly, and more importantly, the compiler
should check that the programmers expression of the system is complete,
valid and consistent. A compiler should perform semantics checking.
This is checking that a program is internally consistent. Generating a
system that has detectable inconsistencies is pointless.
Semantics checking is done by ensuring that a specification conforms
to some schema. For example, the sentence "The boy drank the computer
and switched on the glass of water" is grammatically correct. But the
sentence is nonsense. It does not conform to the mental schema we have
of computers and glasses of water. A programming language should
include techniques for the detection of similar nonsense. The language
definition provides the framework that makes this role of the compiler
possible.
Checking is often enabled by the specification of redundant
information. Declarations are an example of redundancy that help check
for misspellings. Declarations define the vocabulary of a program, ie
the elements in its universe. The compiler uses redundant information
for consistency checking, and strips it away to produce efficient
executable systems. Type safety is another technique. Declarations
also associate an entity with a type, to define the entities role.
Typing ensures that you can't drink computers or switch on glasses of
water. C++ is an improvement over C in type
Page : 1 Next >>