B. Stroustrup - The C++ Programming Language (794319), страница 20
Текст из файла (страница 20)
If you find this ‘‘lightning tour’’confusing, skip to the more systematic presentation starting in Chapter 6.60A Tour of C++: Abstraction MechanismsChapter 3As in Chapter 2, this tour presents C++ as an integrated whole, rather than as a layer cake.Consequently, it does not identify language features as present in C, part of C++98, or new inC++11. Such historical information can be found in §1.4 and Chapter 44.3.2 ClassesThe central language feature of C++ is the class. A class is a user-defined type provided to represent a concept in the code of a program.
Whenever our design for a program has a useful concept,idea, entity, etc., we try to represent it as a class in the program so that the idea is there in the code,rather than just in our head, in a design document, or in some comments. A program built out of awell chosen set of classes is far easier to understand and get right than one that builds everythingdirectly in terms of the built-in types. In particular, classes are often what libraries offer.Essentially all language facilities beyond the fundamental types, operators, and statements existto help define better classes or to use them more conveniently. By ‘‘better,’’ I mean more correct,easier to maintain, more efficient, more elegant, easier to use, easier to read, and easier to reasonabout.
Most programming techniques rely on the design and implementation of specific kinds ofclasses. The needs and tastes of programmers vary immensely. Consequently, the support forclasses is extensive. Here, we will just consider the basic support for three important kinds ofclasses:• Concrete classes (§3.2.1)• Abstract classes (§3.2.2)• Classes in class hierarchies (§3.2.4)An astounding number of useful classes turn out to be of these three kinds.
Even more classes canbe seen as simple variants of these kinds or are implemented using combinations of the techniquesused for these.3.2.1 Concrete TypesThe basic idea of concrete classes is that they behave ‘‘just like built-in types.’’ For example, acomplex number type and an infinite-precision integer are much like built-in int, except of coursethat they have their own semantics and sets of operations. Similarly, a vector and a string are muchlike built-in arrays, except that they are better behaved (§4.2, §4.3.2, §4.4.1).The defining characteristic of a concrete type is that its representation is part of its definition.
Inmany important cases, such as a vector, that representation is only one or more pointers to moredata stored elsewhere, but it is present in each object of a concrete class. That allows implementations to be optimally efficient in time and space. In particular, it allows us to• place objects of concrete types on the stack, in statically allocated memory, and in otherobjects (§6.4.2);• refer to objects directly (and not just through pointers or references);• initialize objects immediately and completely (e.g., using constructors; §2.3.2); and• copy objects (§3.3).The representation can be private (as it is for Vector; §2.3.2) and accessible only through the member functions, but it is present. Therefore, if the representation changes in any significant way, auser must recompile.
This is the price to pay for having concrete types behave exactly like built-inSection 3.2.1Concrete Types61types. For types that don’t change often, and where local variables provide much-needed clarityand efficiency, this is acceptable and often ideal. To increase flexibility, a concrete type can keepmajor parts of its representation on the free store (dynamic memory, heap) and access them throughthe part stored in the class object itself. That’s the way vector and string are implemented; they canbe considered resource handles with carefully crafted interfaces.3.2.1.1 An Arithmetic TypeThe ‘‘classical user-defined arithmetic type’’ is complex:class complex {double re, im; // representation: two doublespublic:complex(double r, double i) :re{r}, im{i} {}complex(double r) :re{r}, im{0} {}complex() :re{0}, im{0} {}// construct complex from two scalars// construct complex from one scalar// default complex: {0,0}double real() const { return re; }void real(double d) { re=d; }double imag() const { return im; }void imag(double d) { im=d; }complex& operator+=(complex z) { re+=z.re, im+=z.im; return ∗this; }// add to re and im// and return the resultcomplex& operator−=(complex z) { re−=z.re, im−=z.im; return ∗this; }complex& operator∗=(complex);complex& operator/=(complex);// defined out-of-class somewhere// defined out-of-class somewhere};This is a slightly simplified version of the standard-library complex (§40.4).
The class definitionitself contains only the operations requiring access to the representation. The representation is simple and conventional. For practical reasons, it has to be compatible with what Fortran provided 50years ago, and we need a conventional set of operators. In addition to the logical demands, complexmust be efficient or it will remain unused. This implies that simple operations must be inlined.That is, simple operations (such as constructors, +=, and imag()) must be implemented without function calls in the generated machine code.
Functions defined in a class are inlined by default. Anindustrial-strength complex (like the standard-library one) is carefully implemented to do appropriate inlining.A constructor that can be invoked without an argument is called a default constructor. Thus,complex() is complex’s default constructor. By defining a default constructor you eliminate the possibility of uninitialized variables of that type.The const specifiers on the functions returning the real and imaginary parts indicate that thesefunctions do not modify the object for which they are called.Many useful operations do not require direct access to the representation of complex, so theycan be defined separately from the class definition:62A Tour of C++: Abstraction Mechanismscomplex operator+(complex a, complex b) { return a+=b; }complex operator−(complex a, complex b) { return a−=b; }complex operator−(complex a) { return {−a.real(), −a.imag()}; }complex operator∗(complex a, complex b) { return a∗=b; }complex operator/(complex a, complex b) { return a/=b; }Chapter 3// unar y minusHere, I use the fact that an argument passed by value is copied, so that I can modify an argumentwithout affecting the caller’s copy, and use the result as the return value.The definitions of == and != are straightforward:bool operator==(complex a, complex b)// equal{return a.real()==b.real() && a.imag()==b.imag();}bool operator!=(complex a, complex b){return !(a==b);}// not equalcomplex sqrt(complex);// ...Class complex can be used like this:void f(complex z){complex a {2.3};// construct {2.3,0.0} from 2.3complex b {1/a};complex c {a+z∗complex{1,2.3}};// ...if (c != b)c = −(b/a)+2∗b;}The compiler converts operators involving complex numbers into appropriate function calls.
Forexample, c!=b means operator!=(c,b) and 1/a means operator/(complex{1},a).User-defined operators (‘‘overloaded operators’’) should be used cautiously and conventionally.The syntax is fixed by the language, so you can’t define a unary /. Also, it is not possible to changethe meaning of an operator for built-in types, so you can’t redefine + to subtract ints.3.2.1.2 A ContainerA container is an object holding a collection of elements, so we call Vector a container because it isthe type of objects that are containers.
As defined in §2.3.2, Vector isn’t an unreasonable containerof doubles: it is simple to understand, establishes a useful invariant (§2.4.3.2), provides rangechecked access (§2.4.3.1), and provides size() to allow us to iterate over its elements. However, itdoes have a fatal flaw: it allocates elements using new but never deallocates them. That’s not agood idea because although C++ defines an interface for a garbage collector (§34.5), it is notSection 3.2.1.2A Container63guaranteed that one is available to make unused memory available for new objects. In some environments you can’t use a collector, and sometimes you prefer more precise control of destruction(§13.6.4) for logical or performance reasons.
We need a mechanism to ensure that the memoryallocated by the constructor is deallocated; that mechanism is a destructor:class Vector {private:double∗ elem;// elem points to an array of sz doublesint sz;public:Vector(int s) :elem{new double[s]}, sz{s}// constructor: acquire resources{for (int i=0; i!=s; ++i) elem[i]=0;// initialize elements}˜Vector() { delete[] elem; }// destructor: release resourcesdouble& operator[](int i);int size() const;};The name of a destructor is the complement operator, ˜, followed by the name of the class; it is thecomplement of a constructor.
Vector’s constructor allocates some memory on the free store (alsocalled the heap or dynamic store) using the new operator. The destructor cleans up by freeing thatmemory using the delete operator. This is all done without intervention by users of Vector. Theusers simply create and use Vectors much as they would variables of built-in types. For example:void fct(int n){Vector v(n);// ... use v ...{Vector v2(2∗n);// ...
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
