《Thinking in C++ 第2版卷2》实战编程

需积分: 10 155 浏览量更新于2024-07-15 收藏 2.58MB PDF 举报

"Thinking_In_C++_2nd_Edition_Volume2.pdf" 《Thinking In C++ 2nd Edition Volume 2》是Bruce Eckel与Chuck Allison合著的经典C++编程教材，该书源自官方内容并由HTML转换为PDF格式。这本书分为三个部分，深入探讨了C++语言的各个方面，旨在帮助读者构建稳定且高效的系统。第一部分：构建稳定系统 1. 异常处理：这部分介绍了如何在C++中有效地处理程序运行时可能出现的错误和异常情况，包括try-catch语句、异常类型和自定义异常，以及何时和如何使用异常处理来提高程序的健壮性。 2. 防御性编程：防患于未然，讲解了如何编写不容易出错的代码，包括避免空指针引用、检查边界条件、使用智能指针等最佳实践，以降低软件缺陷的可能性。第二部分：标准C++库 3. 字符串深入：详细讨论了C++中的字符串类（std::string），包括构造、操作、比较和内存管理，以及如何与其他数据类型相互操作。 4. 输入/输出流：讲解了iostream库，用于进行文件和标准输入输出的处理，包括流对象、格式控制、流插入器和提取器的使用。 5. 模板深入：深入讲解了C++模板的用法，包括函数模板、类模板、模板特化、模板元编程，以及模板的高级技巧。 6. 通用算法：介绍了C++标准库中的各种高效算法，如排序、查找、迭代器操作，以及如何在实际编程中应用这些算法提升代码效率。 7. 通用容器：详细阐述了标准模板库（STL）中的容器，如vector、list、set、map等，以及它们的迭代器和算法的配合使用。第三部分：特殊话题 8. 运行时类型识别：讲述了RTTI（Runtime Type Information）机制，包括dynamic_cast和typeid，以及如何在多态环境中确定对象的实际类型。 9. 多重继承：讨论了C++中多重继承的概念、优势和陷阱，以及如何解决菱形问题和其他潜在冲突。 10. 设计模式：介绍了一些常见的设计模式，如工厂模式、单例模式、观察者模式，以提升代码的可读性和可维护性。 11. 并发编程：涵盖了线程、同步、互斥锁等多线程编程的概念和技术，以及如何在C++中安全地实现并发操作。附录包括推荐的阅读材料和一些补充信息。这本书获得了业界的高度评价，被认为是C++学习者的必备参考书籍，其清晰的解释和准确的技术内容使读者能够掌握C++的核心概念和高级特性。

Any further catch clauses for the same try block are still ignored—the throw causes the exception to go to the exception handlers in the next-

higher context. In addition, everything about the exception object is preserved, so the handler at the higher context that catches the specific

exception type can extract any information the object may contain.

Uncaught exceptions

As we explained in the beginning of this chapter, exception handling is considered better than the traditional return-an-error-code technique

because exceptions can’t be ignored, and because the error handling logic is separated from the problem at hand. If none of the exception

handlers following a particular try block matches an exception, that exception moves to the next-higher context, that is, the function or try

block surrounding the try block that did not catch the exception. (The location of this try block is not always obvious at first glance, since it’s

higher up in the call chain.) This process continues until, at some level, a handler matches the exception. At that point, the exception is

considered “caught,” and no further searching occurs.

The terminate( ) function

If no handler at any level catches the exception, the special library function terminate( ) (declared in the <exception> header) is

automatically called. By default, terminate( ) calls the Standard C library function abort( ) , which abruptly exits the program. On Unix

systems, abort( ) also causes a core dump. When abort( ) is called, no calls to normal program termination functions occur, which means that

destructors for global and static objects do not execute. The terminate( ) function also executes if a destructor for a local object throws an

exception while the stack is unwinding (interrupting the exception that was in progress) or if a global or static object’s constructor or destructor

throws an exception. (In general, do not allow a destructor to throw an exception.)

The set_terminate( ) function

You can install your own terminate( ) function using the standard set_terminate( ) function, which returns a pointer to the terminate( )

function you are replacing (which will be the default library version the first time you call it), so you can restore it later if you want. Your custom

terminate( ) must take no arguments and have a void return value. In addition, any terminate( ) handler you install must not return or

throw an exception, but instead must execute some sort of program-termination logic. If terminate( ) is called, the problem is unrecoverable.

The following example shows the use of set_terminate( ). Here, the return value is saved and restored so that the terminate( ) function can

be used to help isolate the section of code where the uncaught exception occurs:

//: C01:Terminator.cpp

// Use of set_terminate(). Also shows uncaught exceptions.

#include <exception>

#include <iostream>

using namespace std;

void terminator() {

cout << "I'll be back!" << endl;

exit(0);

}

void (*old_terminate)() = set_terminate(terminator);

class Botch {

public:

class Fruit {};

void f() {

cout << "Botch::f()" << endl;

throw Fruit();

}

~Botch() { throw 'c'; }

};

int main() {

try {

Botch b;

b.f();

} catch(...) {

cout << "inside catch(...)" << endl;

}

} ///:~

The definition of old_terminate looks a bit confusing at first: it not only creates a pointer to a function, but it initializes that pointer to the

return value of set_terminate( ). Even though you might be familiar with seeing a semicolon right after a pointer-to-function declaration, here

it’s just another kind of variable and can be initialized when it is defined.

The class Botch not only throws an exception inside f( ), but also in its destructor. This causes a call to terminate( ), as you can see in

main( ). Even though the exception handler says catch(...), which would seem to catch everything and leave no cause for terminate( ) to be

called, terminate( ) is called anyway. In the process of cleaning up the objects on the stack to handle one exception, the Botch destructor is

called, and that generates a second exception, forcing a call to terminate( ). Thus, a destructor that throws an exception or causes one to be

thrown is usually a sign of poor design or sloppy coding.

Cleaning up

Part of the magic of exception handling is that you can pop from normal program flow into the appropriate exception handler. Doing so wouldn’t

be useful, however, if things weren’t cleaned up properly as the exception was thrown. C++ exception handling guarantees that as you leave a

scope, all objects in that scope whose constructors have been completed will have their destructors called.

Here’s an example that demonstrates that constructors that aren’t completed don’t have the associated destructors called. It also shows what

happens when an exception is thrown in the middle of the creation of an array of objects:

//: C01:Cleanup.cpp

// Exceptions clean up complete objects only.

#include <iostream>

using namespace std;

class Trace {

static int counter;

int objid;

public:

Trace() {

objid = counter++;

cout << "constructing Trace #" << objid << endl;

if(objid == 3) throw 3;

}

~Trace() {

cout << "destructing Trace #" << objid << endl;

}

};

int Trace::counter = 0;

int main() {

try {

Trace n1;

// Throws exception:

Trace array[5];

Trace n2; // Won't get here.

} catch(int i) {

cout << "caught " << i << endl;

}

} ///:~

The class Trace keeps track of objects so that you can trace program progress. It keeps a count of the number of objects created with a static

data member counter and tracks the number of the particular object with objid.

The main program creates a single object, n1 (objid 0), and then attempts to create an array of five Trace objects, but an exception is thrown

before the fourth object (#3) is fully created. The object n2 is never created. You can see the results in the output of the program:

constructing Trace #0

constructing Trace #1

constructing Trace #2

constructing Trace #3

destructing Trace #2

destructing Trace #1

destructing Trace #0

caught 3

Three array elements are successfully created, but in the middle of the constructor for the fourth element, an exception is thrown. Because the

fourth construction in main( ) (for array[2]) never completes, only the destructors for objects array[1] and array[0] are called. Finally,

object n1 is destroyed, but not object n2, because it was never created.

Resource management

When writing code with exceptions, it’s particularly important that you always ask, “If an exception occurs, will my resources be properly

cleaned up?” Most of the time you’re fairly safe, but in constructors there’s a particular problem: if an exception is thrown before a constructor

is completed, the associated destructor will not be called for that object. Thus, you must be especially diligent while writing your constructor.

The difficulty is in allocating resources in constructors. If an exception occurs in the constructor, the destructor doesn’t get a chance to

deallocate the resource. This problem occurs most often with “naked” pointers. For example:

//: C01:Rawp.cpp

// Naked pointers.

#include <iostream>

#include <cstddef>

using namespace std;

class Cat {

public:

Cat() { cout << "Cat()" << endl; }

~Cat() { cout << "~Cat()" << endl; }

};

class Dog {

public:

void* operator new(size_t sz) {

cout << "allocating a Dog" << endl;

throw 47;

}

void operator delete(void* p) {

cout << "deallocating a Dog" << endl;

::operator delete(p);

}

};

class UseResources {

Cat* bp;

Dog* op;

public:

UseResources(int count = 1) {

cout << "UseResources()" << endl;

bp = new Cat[count];

op = new Dog;

}

~UseResources() {

cout << "~UseResources()" << endl;

delete [] bp; // Array delete

delete op;

}

};

int main() {

try {

UseResources ur(3);

} catch(int) {

cout << "inside handler" << endl;

}

} ///:~

The output is

UseResources()

Cat()

allocating a Dog

inside handler

The UseResources constructor is entered, and the Cat constructor is successfully completed for the three array objects. However, inside

Dog::operator new( ), an exception is thrown (to simulate an out-of-memory error). Suddenly, you end up inside the handler, without the

UseResources destructor being called. This is correct because the UseResources constructor was unable to finish, but it also means the Cat

objects that were successfully created on the heap were never destroyed.

Making everything an object

To prevent such resource leaks, you must guard against these “raw” resource allocations in one of two ways:

· You can catch exceptions inside the constructor and then release the resource.

· You can place the allocations inside an object’s constructor, and you can place the deallocations inside an object’s destructor.

Using the latter approach, each allocation becomes atomic, by virtue of being part of the lifetime of a local object, and if it fails, the other

resource allocation objects are properly cleaned up during stack unwinding. This technique is called Resource Acquisition Is Initialization (RAII

for short) because it equates resource control with object lifetime. Using templates is an excellent way to modify the previous example to

achieve this:

//: C01:Wrapped.cpp

// Safe, atomic pointers.

#include <iostream>

#include <cstddef>

using namespace std;

// Simplified. Yours may have other arguments.

template<class T, int sz = 1> class PWrap {

T* ptr;

public:

class RangeError {}; // Exception class

PWrap() {

ptr = new T[sz];

cout << "PWrap constructor" << endl;

}

~PWrap() {

delete[] ptr;

cout << "PWrap destructor" << endl;

}

T& operator[](int i) throw(RangeError) {

if(i >= 0 && i < sz) return ptr[i];

throw RangeError();

}

};

class Cat {

public:

Cat() { cout << "Cat()" << endl; }

~Cat() { cout << "~Cat()" << endl; }

void g() {}

};

class Dog {

public:

void* operator new[](size_t) {

cout << "Allocating a Dog" << endl;

throw 47;

}

void operator delete[](void* p) {

cout << "Deallocating a Dog" << endl;

::operator delete[](p);

}

};

class UseResources {

PWrap<Cat, 3> cats;

PWrap<Dog> dog;

public:

UseResources() { cout << "UseResources()" << endl; }

~UseResources() { cout << "~UseResources()" << endl; }

void f() { cats[1].g(); }

};

int main() {

try {

UseResources ur;

} catch(int) {

cout << "inside handler" << endl;

} catch(...) {

cout << "inside catch(...)" << endl;

}

} ///:~

The difference is the use of the template to wrap the pointers and make them into objects. The constructors for these objects are called before

the body of the UseResources constructor, and any of these constructors that complete before an exception is thrown will have their

associated destructors called during stack unwinding.

The PWrap template shows a more typical use of exceptions than you’ve seen so far: A nested class called RangeError is created to use in

operator[ ] if its argument is out of range. Because operator[ ] returns a reference, it cannot return zero. (There are no null references.)

This is a true exceptional condition—you don’t know what to do in the current context and you can’t return an improbable value. In this

example, RangeError is simple and assumes all the necessary information is in the class name, but you might also want to add a member

that contains the value of the index, if that is useful.

Now the output is

Cat()

PWrap constructor

allocating a Dog

~Cat()

PWrap destructor

inside handler

Again, the storage allocation for Dog throws an exception, but this time the array of Cat objects is properly cleaned up, so there is no memory

leak.

auto_ptr

Since dynamic memory is the most frequent resource used in a typical C++ program, the standard provides an RAII wrapper for pointers to

heap memory that automatically frees the memory. The auto_ptr class template, defined in the <memory> header, has a constructor that

takes a pointer to its generic type (whatever you use in your code). The auto_ptr class template also overloads the pointer operators * and ->

to forward these operations to the original pointer the auto_ptr object is holding. So you can use the auto_ptr object as if it were a raw

pointer. Here’s how it works:

//: C01:Auto_ptr.cpp

// Illustrates the RAII nature of auto_ptr.

#include <memory>

#include <iostream>

#include <cstddef>

using namespace std;

class TraceHeap {

int i;

public:

static void* operator new(size_t siz) {

void* p = :: operator new(siz);

cout << "Allocating TraceHeap object on the heap "

<< "at address " << p << endl;

return p;

}

static void operator delete(void* p) {

cout << "Deleting TraceHeap object at address "

<< p << endl;

::operator delete(p);

}

TraceHeap(int i) : i(i) {}

int getVal() const { return i; }

};

int main() {

auto_ptr<TraceHeap> pMyObject(new TraceHeap(5));

cout << pMyObject->getVal() << endl; // Prints 5

} ///:~

The TraceHeap class overloads the operator new and operator delete so you can see exactly what’s happening. Notice that, like any other

class template, you specify the type you’re going to use in a template parameter. You don’t say TraceHeap*, however—auto_ptr already

knows that it will be storing a pointer to your type. The second line of main( ) verifies that auto_ptr’s operator->( ) function applies the

indirection to the original, underlying pointer. Most important, even though we didn’t explicitly delete the original pointer, pMyObject’s

destructor deletes the original pointer during stack unwinding, as the following output verifies:

Allocating TraceHeap object on the heap at address 8930040

Deleting TraceHeap object at address 8930040

The auto_ptr class template is also handy for pointer data members. Since class objects contained by value are always destructed, auto_ptr

[5]

[6]

members always delete the raw pointer they wrap when the containing object is destructed.

Function–level try blocks

Since constructors can routinely throw exceptions, you might want to handle exceptions that occur when an object’s member or base subobjects

are initialized. To do this, you can place the initialization of such subobjects in a function-level try block. In a departure from the usual syntax,

the try block for constructor initializers is the constructor body, and the associated catch block follows the body of the constructor, as in the

following example:

//: C01:InitExcept.cpp {-bor}

// Handles exceptions from subobjects.

#include <iostream>

using namespace std;

class Base {

int i;

public:

class BaseExcept {};

Base(int i) : i(i) { throw BaseExcept(); }

};

class Derived : public Base {

public:

class DerivedExcept {

const char* msg;

public:

DerivedExcept(const char* msg) : msg(msg) {}

const char* what() const { return msg; }

};

Derived(int j) try : Base(j) {

// Constructor body

cout << "This won't print" << endl;

} catch(BaseExcept&) {

throw DerivedExcept("Base subobject threw");;

}

};

int main() {

try {

Derived d(3);

} catch(Derived::DerivedExcept& d) {

cout << d.what() << endl; // "Base subobject threw"

}

} ///:~

Notice that the initializer list in the constructor for Derived goes after the try keyword but before the constructor body. If an exception does

occur, the contained object is not constructed, so it makes no sense to return to the code that created it. For this reason, the only sensible

thing to do is to throw an exception in the function-level catch clause.

Although it is not terribly useful, C++ also allows function-level try blocks for any function, as the following example illustrates:

//: C01:FunctionTryBlock.cpp {-bor}

// Function-level try blocks.

// {RunByHand} (Don’t run automatically by the makefile)

#include <iostream>

using namespace std;

int main() try {

throw "main";

} catch(const char* msg) {

cout << msg << endl;

return 1;

} ///:~

In this case, the catch block can return in the same manner that the function body normally returns. Using this type of function-level try block

isn’t much different from inserting a try-catch around the code inside of the function body.

Standard exceptions

The exceptions used with the Standard C++ library are also available for your use. Generally it’s easier and faster to start with a standard

exception class than to try to define your own. If the standard class doesn’t do exactly what you need, you can derive from it.

All standard exception classes derive ultimately from the class exception, defined in the header <exception>. The two main derived classes

are logic_error and runtime_error, which are found in <stdexcept> (which itself includes <exception>). The class logic_error

represents errors in programming logic, such as passing an invalid argument. Runtime errors are those that occur as the result of unforeseen

forces such as hardware failure or memory exhaustion. Both runtime_error and logic_error provide a constructor that takes a std::string

argument so that you can store a message in the exception object and extract it later with exception::what( ) , as the following program

illustrates:

//: C01:StdExcept.cpp

// Derives an exception class from std::runtime_error.

#include <stdexcept>

#include <iostream>

using namespace std;

class MyError : public runtime_error {

public:

MyError(const string& msg = "") : runtime_error(msg) {}

};

[6]

剩余326页未读，继续阅读

陈业新(Jimmy)

粉丝: 0
资源: 3

《Thinking in C++ 第2版 卷2》实战编程

Thinking In C++ (2nd) Volume 1，Volume 2------英文版

Thinking in C++, Volume 2, 2nd Edition

《Thinking In C++ 2nd Vol1&Vol2 PDF》

Thinking In C++ VolumeII.pdf

Thinking_In_C++_2nd_Edition_Volume1.pdf

Thinking.inC_2nd.edition.Volume.2.Standard.Libraries.Advanced.Topics

Thinking+in+C++,+Volume+1,+2nd+Edition.pdf

Thinking in C++ 2nd edition Volume 2 Standard Libraries & Advanced Topics.pdf

Thinking in C++ 2nd edition Volume 2

Thinking in C++,Volume 1, 2nd Edition

最新资源

《Thinking in C++ 第2版卷2》实战编程