Effective STL：优化C++标准模板库实践指南

需积分: 10 162 浏览量更新于2024-07-21 收藏 1.82MB PDF 举报

"Effective STL" 是一本由 Scott Meyers 编写的关于C++标准模板库（STL）的英文版指南，旨在通过多种应用实例帮助读者深入理解和高效使用STL。书中涵盖了各种容器、迭代器、算法和分配器等关键概念，并提供了实用的编程建议。在STL中，容器是存储和组织对象的基本构造块。以下是书中的部分要点： 1. **选择合适的容器**：不同的容器如vector、list、set和map有不同的性能特点和用途。选择时要考虑访问速度、插入和删除元素的效率等因素。 2. **警惕容器独立代码的幻觉**：虽然STL设计为通用，但不同容器的行为差异可能导致代码在特定容器上表现不佳。 3. **优化容器中对象的拷贝**：确保对象的拷贝构造函数和赋值操作符高效且正确，这对于容器中对象的性能至关重要。 4. **使用empty()而非size()==0**：检查容器是否为空时，直接调用empty()更直观且避免了潜在的错误。 5. **优先使用范围版本的成员函数**：例如，使用`std::for_each`代替单个元素的迭代，可以提高代码的可读性和效率。 6. **注意C++的最烦人的解析**：在某些情况下，C++的语法可能会导致意外的隐式类型转换，需要小心处理。 7. **管理动态分配的指针容器**：当容器存储new分配的指针时，必须在容器销毁前删除这些指针，防止内存泄漏。 8. **避免使用auto_ptr于容器中**：由于auto_ptr的特殊所有权规则，与STL容器结合使用时容易引发问题。 9. **慎重选择erase操作**：不同的erase方法有不同的效果，如erase()和erase/remove组合，需要根据情况选择。 10. **了解分配器的约定和限制**：分配器控制STL容器如何管理内存，了解其工作原理可以更好地定制和优化容器。 11. **定制分配器的合理使用**：虽然可以自定义分配器，但并非所有情况都需要，需谨慎评估需求。 12. **对STL容器的线程安全性有实际期望**：大多数STL容器并不是线程安全的，因此在多线程环境中使用时，需要额外的同步措施。 13. **优先考虑vector和string**：vector提供连续的内存布局，适合随机访问；string是处理文本数据的好选择，它们通常比动态数组更高效。 14. **使用reserve避免不必要的重新分配**：在向vector或string添加元素前调用reserve，可以预先分配足够的空间，减少内存重分配次数。 15. **注意“size_type”和“difference_type”的区别**：它们分别表示容器内元素数量和迭代器之间的差值，选择正确的类型进行计算是必要的。通过深入理解和实践这些要点，开发者可以更有效地利用STL，编写出高效、可维护的C++代码。

vector<Widget> vw;

class SpecialWidget: // SpecialWidget inherits from

public Widget {...}; // Widget above

SpecialWidget sw;

vw.push_back(sw); // sw is copied as a base class

II object into vw. Its specialness

// is lost during the copying

The slicing problem suggests that inserting a derived class object into a container of

base class objects is almost always an error. If you want the resulting object to act like

a derived class object, e.g., invoke derived class virtual functions, etc., it is always an

error. (For more background on the slicing problem, consult Effective C++. Item 22.

For another example of where it arises in the STL, see Item 38.)

An easy way to make copying efficient, correct, and immune to the slicing problem is

to create containers of pointers instead of containers of objects. That is, instead of

creating a container of Widget, create a container of Widget*. Copying pointers is fast,

it always does exactly what you expect (it copies the bits making up the pointer), and

nothing gets sliced when a pointer is copied. Unfortunately, containers of pointers

have their own STL-related headaches. You can read about them in Items 7 and 33. As

you seek to avoid those headaches while still dodging efficiency, correctness, and

slicing concerns, you'll probably discover that containers of smart pointers are an

attractive option. To learn more about this option, turn to Item 7.

If all this makes it sound like the STL is copy-crazy, think again. Yes, the STL makes

lots of copies, but it's generally designed to avoid copying objects unnecessarily. In

fact, it's generally designed to avoid creating objects unnecessarily. Contrast this with

the behavior of C's and C++'s only built-in container, the lowly array:

Widget w[maxNumWidgets]; // create an array of maxNumWidgets

// Widgets, default-constructing each one

This constructs maxNumWidgets Widget objects, even if we normally expect to use

only a few of them or we expect to immediately overwrite each default-constructed

value with values we get from someplace else (e.g., a file). Using the STL instead of

an array, we can use a vector that grows when it needs to:

vector<Widget> vw; // create a vector with zero Widget

// objects that will expand as needed

We can also create an empty vector that contains enough space for maxNumWidgets

Widgets, but where zero Widgets have been constructed:

vector<Widget> vw;

vw.reserve(maxNumWidgets); // see Item 14 for details on reserve

Compared to arrays. STL containers are much more civilized. They create (by

copying) only as many objects as you ask for, they do it only when you direct them to,

and they use a default constructor only when you say they should. Yes, STL containers

make copies, and yes, you need to understand that, but don't lose sight of the fact that

they're still a big step up from arrays.

Item 4. Call empty instead of checking size() against zero.

For any container c, writing

if (c.size() == 0)...

is essentially equivalent to writing

if (c.empty())...

That being the case, you might wonder why one construct should be preferred to the

other, especially in view of the fact that empty is typically implemented as an inline

function that simply returns whether size returns 0.

You should prefer the construct using empty, and the reason is simple: empty is a

constant-time operation for all standard containers, but for some list implementations,

size takes linear time.

But what makes list so troublesome? Why can't it, too. offer a constant-time size? The

answer has much to do with list's unique splicing functions. Consider this code:

list<int> list1;

list<int> list2;

...

list1.splice( // move ail nodes in list2

list1.end(), list2, // from the first occurrence

find(list2.begin(), list2.end(), 5), // of 5 through the last

find(list2.rbegin(), list2.rend(), 10).base() // occurrence of 10 to the

); //end of list1. See Item 28

// for info on the "base()" call

This code won't work unless list2 contains a 10 somewhere beyond a 5, but let's

assume that's not a problem. Instead, let's focus on this question: how many elements

are in list1 after the splice? Clearly, list1 after the splice has as many elements as it did

before the splice plus however many elements were spliced into it. But how many

elements were spliced into it? As many as were in the range defined by

find(list2.begin(), list2.end(), 5) and find(list2.rbegin(), list2.rend(), 10).base(). Okay,

how many is that? Without traversing the range and counting them, there's no way to

know. And therein lies the problem.

Suppose you're responsible for implementing list, list isn't just any container, it's a

standard container, so you know your class will be widely used. You naturally want

your implementation to be as efficient as possible. You figure that clients will

commonly want to find out how many elements are in a list, so you'd like to make size

a constant- time operation. You'd thus like to design list so it always knows how many

elements it contains.

At the same time, you know that of all the standard containers, only list offers the

ability to splice elements from one place to another without copying any data. You

reason that many list clients will choose list specifically because it offers high-

efficiency splicing. They know that splicing a range from one list to another can be

accomplished in constant time, and you know that they know it, so you certainly want

to meet their expectation that splice is a constant-time member function.

This puts you in a quandary. If size is to be a constant-time operation, each list

member function must update the sizes of the lists on which it operates. That includes

splice. But the only way for splice to update the sizes of the lists it modifies is for it to

count the number of elements being spliced, and doing that would prevent splice from

achieving the constant-time performance you want for it. If you eliminate the

requirement that splice update the sizes of the lists it's modifying, splice can be made

constant-time, but then size becomes a linear-time operation. In general, it will have to

traverse its entire data structure to see how many elements it contains. No matter how

you look at it, something — size or splice — has to give. One or the other can be a

constant-time operation, but not both.

Different list implementations resolve this conflict in different ways, depending on

whether their authors choose to maximize the efficiency of size or splice. If you

happen to be using a list implementation where a constant-time splice was given

higher priority than a constant-time size, you'll be better off calling empty than size,

because empty is always a constant-time operation. Even if you're not using such an

implementation, you might find yourself using such an implementation in the future.

For example, you might port your code to a different platform where a different

implementation of the STL is available, or you might just decide to switch to a

different STL implementation for your current platform.

No matter what happens, you can't go wrong if you call empty instead of checking to

see if size() == 0. So call empty whenever you need to know whether a container has

zero elements.

Item 5. Prefer range member functions to their single-element

counterparts.

Quick! Given two vectors, v1 and v2, what's the easiest way to make v1’s contents be

the same as the second half of v2's? Don't agonize over the definition of "half when v2

has an odd number of elements, just do something reasonable.

Time's up! If your answer was

v1.assign(v2.begin() + v2.size() /2, v2.end());

or something quite similar, you get full credit and a gold star. If your answer involved

more than one function call, but didn't use any kind of loop, you get nearly full credit,

but no gold star. If your answer involved a loop, you've got some room for

improvement, and if your answer involved multiple loops, well, let's just say that you

really need this book.

By the way, if your response to the answer to the question included "Huh?", pay close

attention, because you're going to learn something really useful.

This quiz is designed to do two things. First, it affords me an opportunity to remind

you of the existence of the assign member function, a convenient beast that too many

programmers overlook. It's available for all the standard sequence containers (vector,

string, deque, and list). Whenever you have to completely replace the contents of a

container, you should think of assignment. If you're just copying one container to

another of the same type, operator= is the assignment function of choice, but as this

example demonstrates, assign is available for the times when you want to give a

container a completely new set of values, but operator= won't do what you want.

The second reason for the quiz is to demonstrate why range member functions are

superior to their single-element alternatives. A range member function is a member

function that, like STL algorithms, uses two iterator parameters to specify a range of

elements over which something should be done. Without using a range member

function to solve this Item's opening problem, you'd have to write an explicit loop,

probably something like this:

vector<Widget> v1, v2; // assume v1 and v2 are vectors

//of Widgets

v1.clear();

for ( vector<Widget>::const_iterator ci = v2.begin() + v2.size() / 2;

ci != v2.end();

++ci)

v1.push_back(*ci);

Item 43 examines in detail why you should try to avoid writing explicit loops, but you

don't need to read that Item to recognize that writing this code is a lot more work than

is writing the call to assign. As we'll see shortly, the loop also happens to impose an

efficiency penalty, but we'll deal with that in a moment.

One way to avoid the loop is to follow the advice of Item 43 and employ an algorithm

instead:

v1.clear();

copy(v2.begin() + v2.size() / 2, v2.end(), back_inserter(v1 ));

Writing this is still more work than writing the call to assign. Furthermore, though no

loop is present in this code, one certainly exists inside copy (see Item 43). As a result,

the efficiency penalty remains. Again. I'll discuss that below. At this point, I want to

digress briefly to observe that almost all uses of copy where the destination range is

specified using an insert iterator (i.e., via inserter, back_inserter, or front_inserter) can

be — should be — replaced with calls to range member functions. Here, for example,

the call to copy can be replaced with a range version of insert:

v1 .insert(v1 .end(), v2.begin() + v2.size() / 2, v2.end());

This involves slightly less typing than the call to copy, but it also says more directly

what is happening: data is being inserted into v1. The call to copy expresses that, too,

but less directly. It puts the emphasis in the wrong place. The interesting aspect of

what is happening is not that elements are being copied, it's that v1 is having new data

added to it. The insert member function makes that clear. The use of copy obscures it.

There's nothing interesting about the fact that things are being copied, because the STL

is built on the assumption that things will be copied. Copying is so fundamental to the

STL, it's the topic of Item 3 in this book!

Too many STL programmers overuse copy, so the advice I just gave bears repeating:

Almost all uses of copy where the destination range is specified using an insert iterator

should be replaced with calls to range member functions.

Returning to our assign example, we've already identified two reasons to prefer range

member functions to their single-element counterparts.

•

It's generally less work to write the code using the range member functions.

•

Range member functions tend to lead to code that is clearer and more

straightforward.

In short, range member functions yield code that is easier to write and easier to

understand. What's not to like?

Alas, some will dismiss these arguments as matters of programming style, and

developers enjoy arguing about style issues almost as much as they enjoy arguing

about which is the One True Editor. (As if there's any doubt. It's Emacs.) It would be

helpful to have a more universally agreed-upon criterion for establishing the

superiority of range member functions to their single-element counterparts. For the

standard sequence containers, we have one: efficiency. When dealing with the

standard sequence containers, application of single-element member functions makes

more demands on memory allocators, copies objects more frequently, and/or performs

redundant operations compared to range member functions that achieve the same end.

For example, suppose you'd like to copy an array of ints into the front of a vector. (The

data might be in an array instead of a vector in the first place, because the data came

from a legacy C API. For a discussion of the issues that arise when mixing STL

containers and C APIs, see Item 16.) Using the vector range insert function, it's

honestly trivial:

int data[numValues]; // assume numValues is

剩余199页未读，继续阅读

mscej

粉丝: 3
资源: 15

Effective STL：优化C++标准模板库实践指南

Effective STL中文版.pdf 带目录书签 清晰版

Effective STL Effective STL Effective STL

effective stl csdn pan

effective stl 电子书 kindle

effective stl 目录 pdf

effective stl 50条

effective stl带目录

c++ effective stl

effective stl pdf

effective stlpdf

最新资源

Effective STL中文版.pdf 带目录书签清晰版