![](https://csdnimg.cn/release/download_crawler_static/10997021/bg12.jpg)
8 Notes to the Reader Chapter 1
activity in C
++
. A well-designed user-defined type differs from a built-in type only in the way it is
defined, not in the way it is used. The C
++
standard library described in Part III provides many
examples of such types and their uses. From a user’s point of view, there is little difference
between a built-in type and a type provided by the standard library.
Features that would incur run-time or memory overheads even when not used were avoided in
the design of C
++
. For example, constructs that would make it necessary to store ‘‘housekeeping
information’’ in every object were rejected, so if a user declares a structure consisting of two 16-bit
quantities, that structure will fit into a 32-bit register.
C
++
was designed to be used in a traditional compilation and run-time environment, that is, the
C programming environment on the UNIX system. Fortunately, C
++
was never restricted to UNIX;
it simply used UNIX and C as a model for the relationships between language, libraries, compilers,
linkers, execution environments, etc. That minimal model helped C
++
to be successful on essen-
tially every computing platform. There are, however, good reasons for using C
++
in environments
that provide significantly more support. Facilities such as dynamic loading, incremental compila-
tion, and a database of type definitions can be put to good use without affecting the language.
C
++
type-checking and data-hiding features rely on compile-time analysis of programs to pre-
vent accidental corruption of data. They do not provide secrecy or protection against someone who
is deliberately breaking the rules. They can, however, be used freely without incurring run-time or
space overheads. The idea is that to be useful, a language feature must not only be elegant; it must
also be affordable in the context of a real program.
For a systematic and detailed description of the design of C
++
, see [Stroustrup,1994].
1.3.1 Efficiency and Structure
C
++
was developed from the C programming language and, with few exceptions, retains C as a
subset. The base language, the C subset of C
++
, is designed to ensure a very close correspondence
between its types, operators, and statements and the objects that computers deal with directly: num-
bers, characters, and addresses. Except for the n ne ew w, d de el le et te e, t ty yp pe ei id d, d dy yn na am mi ic c_ _c ca as st t, and t th hr ro ow w oper-
ators and the try-block, individual C
++
expressions and statements need no run-time support.
C
++
can use the same function call and return sequences as C – or more efficient ones. When
even such relatively efficient mechanisms are too expensive, a C
++
function can be substituted
inline, so that we can enjoy the notational convenience of functions without run-time overhead.
One of the original aims for C was to replace assembly coding for the most demanding systems
programming tasks. When C
++
was designed, care was taken not to compromise the gains in this
area. The difference between C and C
++
is primarily in the degree of emphasis on types and struc-
ture. C is expressive and permissive. C
++
is even more expressive. However, to gain that increase
in expressiveness, you must pay more attention to the types of objects. Knowing the types of
objects, the compiler can deal correctly with expressions when you would otherwise have had to
specify operations in painful detail. Knowing the types of objects also enables the compiler to
detect errors that would otherwise persist until testing – or even later. Note that using the type sys-
tem to check function arguments, to protect data from accidental corruption, to provide new types,
to provide new operators, etc., does not increase run-time or space overheads in C
++
.
The emphasis on structure in C
++
reflects the increase in the scale of programs written since C
was designed. You can make a small program (say, 1,000 lines) work through brute force even
The C++ Programming Language, Special Edition by Bjarne Stroustrup. Copyright 2000 by AT&T.
Published by Addison Wesley, Inc. ISBN 0-201-70073-5. All rights reserved.