提升C++编程技巧：第3版实战指南

需积分: 9 137 浏览量更新于2024-07-22 收藏 1.5MB PDF 举报

《Effective C++ (3rd Edition)》是由Scott Meyers撰写的一本深受全球程序员喜爱的经典书籍，它专注于提升C++编程实践和设计的质量。此书第三版于2005年5月由Addison Wesley Professional出版社发行，其ISBN为0-321-33487-6，共320页，内容丰富，分为55个具体的指导原则，每个原则都围绕如何编写更清晰、正确和高效的C++代码展开。在之前的版本基础上，这一新版增加了大量新内容，包括了对资源管理的专门章节和模板的深入讨论，这些都是对原有内容的重大扩展。对于已经涵盖在第二版中的主题，如异常处理、设计模式以及多线程，作者进行了详尽的修订，使其更好地反映了现代设计的最佳实践。本书的特点在于提供专家级的指导，让读者能够遵循书中所述的经验法则（rules of thumb），避免常见的陷阱，并学习专家们常用的设计策略和编程技巧。阅读《Effective C++ (3rd Edition)》，程序员可以期待从以下方面获得提升： 1. **实践规则**：55条具体建议，每一条都是专家在实际项目中运用的智慧结晶，旨在优化代码结构和性能。 2. **实例支持**：每一条原则后面都有具体的代码示例，便于读者理解和应用。 3. **与时俱进**：新章节涵盖了现代C++语言特性，如资源管理、模板的高级用法、异常处理等，确保内容与技术发展同步。 4. **设计改进**：对第二版中的内容进行修订，反映了当前最佳设计实践，如设计模式的最新理解及多线程编程的最佳实践。 5. **效率提升**：通过学习和遵循书中的策略，开发者能写出既正确又高效的代码，避免常见错误。《Effective C++ (3rd Edition)》是一本不可或缺的参考书，无论你是C++初学者还是资深开发者，都能从中收获实用的编程经验和设计思路，帮助你在C++的世界里更加游刃有余。

Item 3: Use const whenever possible

file:///C|/Users/Administrator/Desktop/EffectiveC++/0321334876/ch01lev1sec3.html[2015/2/10 15:26:41]

std::vector<int>::const_iterator cIter = //cIter acts like a const T*

vec.begin();

*cIter = 10; // error! *cIter is const

++cIter; // fine, changes cIter

Some of the most powerful uses of const stem from its application to function declarations. Within a function declaration, const can refer to the

function's return value, to individual parameters, and, for member functions, to the function as a whole.

Having a function return a constant value often makes it possible to reduce the incidence of client errors without giving up safety or efficiency. For

example, consider the declaration of the

operator* function for rational numbers that is explored in Item 24.

class Rational { ... };

const Rational operator*(const Rational& lhs, const Rational& rhs);

Many programmers squint when they first see this. Why should the result of operator* be a const object? Because if it weren't, clients would be

able to commit atrocities like this:

Rational a, b, c;

...

(a * b) = c; // invoke operator= on the

// result of a*b!

I don't know why any programmer would want to make an assignment to the product of two numbers, but I do know that many programmers have

tried to do it without wanting to. All it takes is a simple typo (and a type that can be implicitly converted to

bool):

if (a * b = c) ... // oops, meant to do a comparison!

Such code would be flat-out illegal if a and b were of a built-in type. One of the hallmarks of good user-defined types is that they avoid gratuitous

incompatibilities with the built-ins (see also Item 18), and allowing assignments to the product of two numbers seems pretty gratuitous to me.

Declaring

operator*'s return value const prevents it, and that's why it's The Right Thing To Do.

There's nothing particularly new about

const parameters — they act just like local const objects, and you should use both whenever you can.

Unless you need to be able to modify a parameter or local object, be sure to declare it

const. It costs you only the effort to type six characters, and

it can save you from annoying errors such as the "I meant to type '==' but I accidently typed '='" mistake we just saw.

const Member Functions

The purpose of const on member functions is to identify which member functions may be invoked on const objects. Such member functions are

important for two reasons. First, they make the interface of a class easier to understand. It's important to know which functions may modify an

object and which may not. Second, they make it possible to work with

const objects. That's a critical aspect of writing efficient code, because, as

Item 20 explains, one of the fundamental ways to improve a C++ program's performance is to pass objects by reference-to-

const. That technique is

viable only if there are

const member functions with which to manipulate the resulting const-qualified objects.

Many people overlook the fact that member functions differing only in their constness can be overloaded, but this is an important feature of C++.

Consider a class for representing a block of text:

class TextBlock {

Item 3: Use const whenever possible

file:///C|/Users/Administrator/Desktop/EffectiveC++/0321334876/ch01lev1sec3.html[2015/2/10 15:26:41]

public:

...

const char& operator[](std::size_t position) const // operator[] for

{ return text[position]; } // const objects

char& operator[](std::size_t position) // operator[] for

{ return text[position]; } // non-const objects

private:

std::string text;

};

TextBlock's operator[]s can be used like this:

TextBlock tb("Hello");

std::cout << tb[0]; // calls non-const

// TextBlock::operator[]

const TextBlock ctb("World");

std::cout << ctb[0]; // calls const TextBlock::operator[]

Incidentally, const objects most often arise in real programs as a result of being passed by pointer- or reference-to-const. The example of ctb

above is artificial. This is more realistic:

void print(const TextBlock& ctb) // in this function, ctb is const

{

std::cout << ctb[0]; // calls const TextBlock::operator[]

...

}

By overloading operator[] and giving the different versions different return types, you can have const and non-const TextBlocks handled

differently:

std::cout << tb[0]; // fine — reading a

// non-const TextBlock

tb[0] = 'x'; // fine — writing a

// non-const TextBlock

std::cout << ctb[0]; // fine — reading a

// const TextBlock

ctb[0] = 'x'; // error! — writing a

// const TextBlock

Note that the error here has only to do with the return type of the operator[] that is called; the calls to operator[] themselves are all fine. The

error arises out of an attempt to make an assignment to a

const char&, because that's the return type from the const version of operator[].

Item 3: Use const whenever possible

file:///C|/Users/Administrator/Desktop/EffectiveC++/0321334876/ch01lev1sec3.html[2015/2/10 15:26:41]

Also note that the return type of the non-const operator[] is a reference to a char — a char itself would not do. If operator[] did return a

simple

char, statements like this wouldn't compile:

tb[0] = 'x';

That's because it's never legal to modify the return value of a function that returns a built-in type. Even if it were legal, the fact that C++ returns

objects by value (see Item 20) would mean that a copy of

tb.text[0] would be modified, not tb.text[0] itself, and that's not the behavior you

want.

Let's take a brief time-out for philosophy. What does it mean for a member function to be

const? There are two prevailing notions: bitwise

constness (also known as physical constness) and logical constness.

The bitwise

const camp believes that a member function is const if and only if it doesn't modify any of the object's data members (excluding those

that are static), i.e., if it doesn't modify any of the bits inside the object. The nice thing about bitwise constness is that it's easy to detect violations:

compilers just look for assignments to data members. In fact, bitwise constness is C++'s definition of constness, and a

const member function isn't

allowed to modify any of the non-static data members of the object on which it is invoked.

Unfortunately, many member functions that don't act very

const pass the bitwise test. In particular, a member function that modifies what a pointer

points to frequently doesn't act

const. But if only the pointer is in the object, the function is bitwise const, and compilers won't complain. That

can lead to counterintuitive behavior. For example, suppose we have a

TextBlock-like class that stores its data as a char* instead of a string,

because it needs to communicate through a C API that doesn't understand

string objects.

class CTextBlock {

public:

...

char& operator[](std::size_t position) const // inappropriate (but bitwise

{ return pText[position]; } // const) declaration of

// operator[]

private:

char *pText;

};

This class (inappropriately) declares operator[] as a const member function, even though that function returns a reference to the object's internal

data (a topic treated in depth in Item 28). Set that aside and note that

operator[]'s implementation doesn't modify pText in any way. As a result,

compilers will happily generate code for

operator[]; it is, after all, bitwise const, and that's all compilers check for. But look what it allows to

happen:

const CTextBlock cctb("Hello"); // declare constant object

char *pc = &cctb[0]; // call the const operator[] to get a

// pointer to cctb's data

*pc = 'J'; // cctb now has the value "Jello"

Surely there is something wrong when you create a constant object with a particular value and you invoke only const member functions on it, yet

you still change its value!

This leads to the notion of logical constness. Adherents to this philosophy argue that a

const member function might modify some of the bits in the

object on which it's invoked, but only in ways that clients cannot detect. For example, your

CTextBlock class might want to cache the length of the

textblock whenever it's requested:

class CTextBlock {

Item 3: Use const whenever possible

file:///C|/Users/Administrator/Desktop/EffectiveC++/0321334876/ch01lev1sec3.html[2015/2/10 15:26:41]

Avoiding Duplication in const and Non-const Member Functions

mutable is a nice solution to the bitwise-constness-is-not-what-I-had-in-mind problem, but it doesn't solve all const-related difficulties. For

example, suppose that

operator[] in TextBlock (and CTextBlock) not only returned a reference to the appropriate character, it also performed

bounds checking, logged access information, maybe even did data integrity validation. Putting all this in both the

const and the non-const

operator[] functions (and not fretting that we now have implicitly inline functions of nontrivial length — see Item 30) yields this kind of

monstrosity:

class TextBlock {

public:

...

const char& operator[](std::size_t position) const

{

... // do bounds checking

... // log access data

... // verify data integrity

return text[position];

}

char& operator[](std::size_t position)

{

... // do bounds checking

... // log access data

... // verify data integrity

return text[position];

}

private:

std::string text;

};

Ouch! Can you say code duplication, along with its attendant compilation time, maintenance, and code-bloat headaches? Sure, it's possible to move

all the code for bounds checking, etc. into a separate member function (private, naturally) that both versions of

operator[] call, but you've still got

the duplicated calls to that function and you've still got the duplicated

return statement code.

What you really want to do is implement

operator[] functionality once and use it twice. That is, you want to have one version of operator[] call

the other one. And that brings us to casting away constness.

As a general rule, casting is such a bad idea, I've devoted an entire Item to telling you not to do it (Item 27), but code duplication is no picnic,

either. In this case, the

const version of operator[] does exactly what the non-const version does, it just has a const-qualified return type.

Casting away the

const on the return value is safe, in this case, because whoever called the non-const operator[] must have had a non-const

object in the first place. Otherwise they couldn't have called a non-const function. So having the non-const operator[] call the const version is a

safe way to avoid code duplication, even though it requires a cast. Here's the code, but it may be clearer after you read the explanation that follows:

class TextBlock {

public:

...

const char& operator[](std::size_t position) const // same as before

{

剩余294页未读，继续阅读

Training-set

粉丝: 1
资源: 1

提升C++编程技巧：第3版实战指南

Effectivec++英文版

Effective C++第三版高清英文原版

Effective C++ PDF

EffectiveC++终稿44__tagged_2019-06241

src_themselves9sm_effectiveC++_zip_

EffectiveC++ 中文版 & EffectiveC++ 3rd 英文版

12_DeathMath_Sette_effectiveC++_

EffectiveC++SecondEdition(中文版）传说中很牛的.pdf

effectiveC++.pdf

EffectiveC++（英文版）

最新资源