Accelerated C++的笔记(31)

>我来写笔记

按有用程度 按页码先后 最新笔记

16.1

Universe (Hello, world.)

16.1 Use the abstractions you have In particular, if we design our own abstractions well, we should be able to use them to solve problems that we had not considered when we designed them. (更多)

16.1 Use the abstractions you have
In particular, if we design our own abstractions well, we should be able to use them to solve problems that we had not considered when we designed them.
(收起)

2011-08-03 22:20:35 回应

收藏
推荐
15.1

Universe (Hello, world.)
这一张讲的是设计，有人对我说过，写代码不值钱，设计才值钱。不过值钱的东西往往不容易理解，像这章就是。将现实问题分解，然后再重新构成软件，本身就是一个费脑筋的过程。要把这个过程给不了解的人讲清楚，就更费脑筋了。这一章的讲解只能说合格，没有前面的章节那么容易理解。 15.1.1 Using inheritance to model the structure We'll call the derived classes String_Pic, for pictures created from strings that our u... (更多)
这一张讲的是设计，有人对我说过，写代码不值钱，设计才值钱。不过值钱的东西往往不容易理解，像这章就是。将现实问题分解，然后再重新构成软件，本身就是一个费脑筋的过程。要把这个过程给不了解的人讲清楚，就更费脑筋了。这一章的讲解只能说合格，没有前面的章节那么容易理解。
15.1.1 Using inheritance to model the structure
We'll call the derived classes String_Pic, for pictures created from strings that our user gives us; Frame_Pic, for a picture created by framing another picture; and HCat_Pic and VCat_Pic, for pictures that are the result of concatenating two other pictures horizontally or vertically respectively. By relating these classes through inheritance, we can use virtual functions to write code that doesn't always need to know the precise kind of picture on which it is operating. That way, our users can still use any of our operations without knowing which kind of picture is being manipulated. We will derive each of these classes from a common base class, which we shall call Pic_base, resulting in the following inheritance hierarchy:

String_Pic 创建 strings 形成的图案（picture）；Frame_Pic 创建装饰 strings 的框（frame）；HCat_Pic 和 VCat_Pic 水平或垂直的组合不同的图案（pictures）。
The next question to resolve is whether to make the inheritance hierarchy visible to our users. There seems to be little reason to do so. None of our operations deals with specific kinds of pictures; instead, they all deal with the abstract notion of a picture. So, there is no need to expose the hierarchy. Moreover, because we intend to use a reference- counting strategy, our users will find it more convenient if we hide the inheritance and associated reference counting. Instead of making our users deal directly with Pic_base and its associated derived classes, we'll define a picture-specific interface class. Our users will access that class, freeing them from having to be aware of any of our implementation's details. In particular, using an interface class will hide the inheritance hierarchy, along with the fact that our class relies on Ptr. Apparently, then we'll need to define six classes: the interface class, the base class for our inheritance hierarchy, and the four derived classes. We'll call the interface class Picture. Internally, Picture will use a Ptr to manage its data.
为了隐藏细节，提供了接口类（interface class），具体实现类不提供 public interface，后面为了实现时能互相调用成员函数（member function），用了友元（friend）。这符合高内聚、低耦合的原则。
So far, the Picture class is pretty simple: The only operation is to create a Picture from a vector of strings. We use a default argument (§7.3/127) to make that vector optional. If a user constructs a Picture with no argument, then the compiler will supply vector<string>() as an argument automatically, which yields a vector<string> with no elements. Therefore, the effect of the default argument is to allow us to use a definition such as
```
Picture p;       // an empty Picture
```
to create a Picture with no rows.
先想做什么，再想怎么做。 (收起)
2011-07-31 09:07:20 回应

收藏
推荐
15.2

Universe (Hello, world.)

15.2.3 Padding the output Static members (both functions and static data members, which we can also define) are useful in that they let us minimize the names that are defined globally. Our pad function is a good example. We can imagine many abstractions that have the notion of padding. In this book we talked about padding in the context of writing a formatted report of student grades, as well a... (更多)

15.2.3 Padding the output
Static members (both functions and static data members, which we can also define) are useful in that they let us minimize the names that are defined globally. Our pad function is a good example. We can imagine many abstractions that have the notion of padding. In this book we talked about padding in the context of writing a formatted report of student grades, as well as in the context of writing Pictures. If the Picture class were to define pad as a global function, then we would not also be able to define a pad function for Student_info, or vice versa. By making pad a static member, we allow for the fact that other abstractions in our program might have the notion of padding. As long as each class defines what pad means only in the context of the class, these mutually independent notions of padding can coexist within our program.
关于 static function 的用途。
A member of a derived class (such as Frame_Pic) can access the protected members of the base-class parts of objects of its own class (such as Frame_Pic), or of other classes derived from it, but it cannot access the protected members of base-class objects that stand alone—that is, that are not part of a derived-class object. Therefore, member functions of class Frame_Pic, which is derived from class Pic_base, can access protected members of the Pic_base parts of Frame_Pic objects, or objects of classes derived from Frame_Pic, but they cannot access protected members of stand-alone Pic_base objects directly.
Protected members 的访问限制。 (收起)

2011-07-29 17:21:50 回应

收藏
推荐
14.4

Universe (Hello, world.)
14.4.1 Copying types that we can't control Solutions to tough problems such as this one often involve what we jokingly call the fundamental theorem of software engineering: All problems can be solved by introducing an extra level of indirection. The problem is that we are trying to call a member function that does not exist, and we have no way to cause the member function to exist. The solution... (更多)
14.4.1 Copying types that we can't control
Solutions to tough problems such as this one often involve what we jokingly call the fundamental theorem of software engineering: All problems can be solved by introducing an extra level of indirection. The problem is that we are trying to call a member function that does not exist, and we have no way to cause the member function to exist. The solution, then, is not to call the member function directly but to define an intermediary global function that we can both call and create. We will still call this new function clone
```
template<class T> T* clone(const T* tp)
{
    return tp->clone();
}
```
and change our make_unique member to call it
```
template<class T>
void Ptr<T>::make_unique()
{
    if (*refptr != 1) {
        --*refptr;
        refptr = new size_t(1);
        p = p ? clone(p): 0;   // call the global (not member) version of clone
    }
}
```
It should be clear that introducing this intermediary function does not change the behavior of make_unique. It still calls clone, which still calls the clone member of the object that is being copied. However, make_unique now works through a level of indirection: It calls the nonmember clone function, which in turn calls the clone member for the object to which p points. For classes such as Student_info that define clone, this indirection buys us nothing. But for classes such as Str that hold Ptrs to types that do not provide a clone function, the indirection is exactly what we need to make the whole thing work. For these latter types, we can define yet another intermediary function:
```
// the key to making Ptr< Vec<char> > work
template<>
Vec<char>* clone(const Vec<char>* vp)
{
    return new Vec<char>(*vp);
}
```
The use of template<> at the beginning of this function indicates that the function is a template specialization. Such specializations define a particular version of a template function for the specific argument type. By defining this specialization, we are saying that clone behaves differently when we give it a pointer to a Vec<char> than it behaves when we give it any other pointer type. When we pass clone a Vec<char>* argument, the compiler will use this specialized version of clone. When we pass other types of pointers, it will instantiate the general template form of clone, which calls the member clone for the pointer that it was passed. Our specialized version uses the Vec<char> copy constructor to construct a new Vec<char> from the one that we gave it. It is true that this specialization of clone does not offer virtual behavior, but we do not need it to do so because there are no classes derived from Vec. What we have done, then, is to moderate our reliance on the clone member by recognizing that the member might not exist. By introducing the extra indirection, we have made it possible to specialize the clone template to do whatever is appropriate to copy an object of a particular class, be it to use a clone member, to call a copy constructor, or something else entirely. In the absence of a specialization, the Ptr class will use the clone member, but it will do so only if there is a call to make_unique. In other words If you use Ptr<T> but you don't use Ptr<T>::make_unique, then it doesn't matter whether T::clone is defined. If you use Ptr<T>::make_unique, and T::clone is defined, make_unique will use T::clone. If you use Ptr<T>::make_unique, and you don't want to use T::clone (perhaps because it doesn't exist), you can specialize clone<T> to do whatever you want.
模板偏特化（template specialization）的用法。 (收起)
2011-07-28 08:38:31 回应

收藏
推荐
14.2

Universe (Hello, world.)
14.2 Reference-counted handles We have added a second data member to our Ref_handle class, and updated the constructors to initialize that new member. The default constructor and the constructor that takes a T* create new Ref_handle objects, so they allocate a new reference count (of type size_t) and set the value of that counter to 1. The copy constructor doesn't create a new object. Instead, ... (更多)
14.2 Reference-counted handles
We have added a second data member to our Ref_handle class, and updated the constructors to initialize that new member. The default constructor and the constructor that takes a T* create new Ref_handle objects, so they allocate a new reference count (of type size_t) and set the value of that counter to 1. The copy constructor doesn't create a new object. Instead, it copies the pointers from the Ref_handle<T> object that it was passed, and increments the reference count to indicate that there is one more pointer to the T object than there was previously. Thus, the new Ref_handle<T> object points to the same T object, and to the same reference count, as the Ref_handle<T> object from which we copy. So, for example, if X is a Ref_handle<T> object, and we create Y as a copy of X, then the situation looks like this:

Ref_handle

The assignment operator also manipulates the reference count instead of copying the underlying object:
```
template<class T>
Ref_handle<T>& Ref_handle<T>::operator=(const Ref_handle& rhs)
{
    ++*rhs.refptr;
    // free the left-hand side, destroying pointers if appropriate 
    if (--*refptr == 0) {
        delete refptr;
        delete p;
    }

    // copy in values from the right-hand side 
    refptr = rhs.refptr;
    p = rhs.p;
    return *this;
}
```
As always, it is important to protect against self-assignment, which we do by incrementing the reference count of the right-hand side before decrementing the reference count of the left-hand side. If both operands refer to the same object, the net effect will be to leave the reference count unchanged, while ensuring that it will not reach zero unintentionally. If the reference count goes to zero when we decrement it, then the left operand is the last Ref_handle bound to the underlying object. Because we are about to obliterate the value of the left operand, we are about to delete the last reference to that object. Therefore, we must delete the object, and its corresponding reference count before we overwrite the values in refptr and p. We delete both p and refptr because both were dynamically allocated objects; thus, we must free them to avoid a memory leak.
引用计数（reference count）说的比较清楚。 (收起)
2011-07-19 11:50:38 回应

收藏
推荐
14.1

Universe (Hello, world.)
14.1.1 A generic handle class The -> operator is a bit more complicated. Superficially, -> looks like a binary operator, but in fact it behaves differently from ordinary binary operators. Like the scope or dot operators, the -> operator is used to access a member whose name appears in its right operand from an object named by its left operand. Because names are not expressions, we have... (更多)
14.1.1 A generic handle class
The -> operator is a bit more complicated. Superficially, -> looks like a binary operator, but in fact it behaves differently from ordinary binary operators. Like the scope or dot operators, the -> operator is used to access a member whose name appears in its right operand from an object named by its left operand. Because names are not expressions, we have no direct access to the name that our user requested. Instead, the language requires that we define -> to return a value that can be treated as a pointer. When we define operator->, we are saying that if x is a value of type that defines operator-> then
```
x->y
```
is equivalent to
```
(x.operator->())->y
```
(收起)
2011-07-18 22:26:57 回应

收藏
推荐
13.6

Universe (Hello, world.)
13.6.1 Inheritance and containers What may be more surprising is what would happen if we persisted in defining a vector<Core> into which we intended to place either Core objects or Grad objects. The answer is that we could do so, but the results would probably be a surprise; for example /代码内容已省略/ We are allowed to store the Grad object in students... (更多)
13.6.1 Inheritance and containers
What may be more surprising is what would happen if we persisted in defining a vector<Core> into which we intended to place either Core objects or Grad objects. The answer is that we could do so, but the results would probably be a surprise; for example
```
vector<Core> students;
Grad g(cin);              // read a Grad
students.push_back(g);    // store the Core part(!) of g in students
```
We are allowed to store the Grad object in students, because we can use a Grad object wherever a reference to a Core object is required. The push_back function takes a reference to the vector's element type, so we can pass g to push_back. However, when we put the object into students, only the Core portion of g is copied! As in §13.2.2/235, this behavior is actually what we asked for, although it can be surprising—especially when encountered for the first time. What will happen is that push_back will expect that it was given a Core object, and will construct a Core element, copying only the Core parts of the object, ignoring whatever is specific to the Grad class .
Base class 和 derived class 的关系要明确，涉及指针的时候，delete、push_back 之类的操作要特别小心，否则很容易丢失 member。
13.6.2 Which function do you want?
Now when we look for a function to call, r is a Grad. The regrade function that applies to Grad objects takes two arguments. Even though there is a base-class version that takes a single argument, that version is effectively hidden by the existence of regrade in the derived class. If we want to run the version from the base class, we must call it explicitly:
```
r.Core::regrade(100);    // ok, call Core::regrade
```
If we want to use regrade as a virtual function, we must give it the same interface in the base and derived classes, which we can do by giving the Core version an extra, unused parameter with a default argument:
```
virtual void Core::regrade(double d, double = 0) { final = d; }
```
(收起)
2011-07-17 12:17:21 回应

收藏
推荐
13.4

Universe (Hello, world.)

The handle class is a class which stores data with a pointer or pointers. (更多)

The handle class is a class which stores data with a pointer or pointers. (收起)

2011-07-17 11:59:01 回应

收藏
推荐
13.2

Universe (Hello, world.)
13.2.1 Obtaining a value without knowing the object's type The virtual keyword may be used only inside the class definition. If the functions are defined separately from their declarations, we do not repeat virtual in the definitions. Thus, the definition of Core::grade() need not change. Similarly, the fact that a function is virtual is inherited, so we need not repeat the virtual designation on... (更多)
13.2.1 Obtaining a value without knowing the object's type
The virtual keyword may be used only inside the class definition. If the functions are defined separately from their declarations, we do not repeat virtual in the definitions. Thus, the definition of Core::grade() need not change. Similarly, the fact that a function is virtual is inherited, so we need not repeat the virtual designation on the declaration of grade within the Grad class. We do have to recompile our code with the new Core class definition. Once we have done so, then because the base-class version is virtual, we get the behavior that we need.
13.2.2 Dynamic binding
```
Core c;
Grad g;
Core* p;
Core& r = g;

c.grade();    // statically bound to Core::grade()
g.grade();    // statically bound to Grad::grade()
p->grade();   // dynamically bound, depending on the type of the object to which p points
r.grade();    // dynamically bound, depending on the type of the object to which r refers
```
(收起)
2011-07-14 16:11:20 回应

收藏
推荐
12.3

Universe (Hello, world.)
/代码内容已省略/ The index operators just forward their work to the corresponding Vec operations. It is worth noting that, as we did for class Vec, we define two versions of the index operator—one that can operate on const objects and the other that cannot. By returning a reference to the character, the nonconst version gives write access to the character that ... (更多)
```
class Str {
public:
    // constructors as before
    char& operator[](size_type i) { return data[i]; }
    const char& operator[](size_type i) const { return data[i]; }

private:
    Vec<char> data;
};
```
The index operators just forward their work to the corresponding Vec operations. It is worth noting that, as we did for class Vec, we define two versions of the index operator—one that can operate on const objects and the other that cannot. By returning a reference to the character, the nonconst version gives write access to the character that it returns. The const version returns a reference to a const char, thereby preventing the user from writing to the underlying character. We return const char& instead of a plain char for consistency with the standard string class.
Why two index operators?
12.3.2 Friends
Rather than adding a (public) access function, we can say that the input operator is a friend of class Str. A friend has the same access rights as a member. By making the input operator a friend, we can allow it, along with our member functions, to access the private members of class Str:
```
class Str {
    friend std::istream& operator>>(std::istream&, Str&);
    // as before
};
```
We've added a friend declaration to class Str. This declaration says that the version of operator>> that takes an istream& and a Str& may access the private members of Str. Once we have added this declaration to Str, our input operator will compile.
12.3.4 Mixed-type expressions
It is important to understand the implications of conversion operations. For example,
```
Str greeting = "Hello, " + name + "!"; 
```
gives greeting the same value as if we had written
```
Str temp1('Hello, ");            // Str::Str(const char*)
Str temp2 = temp1 + name;        // operator*(const Str&, const Str&)
Str temp3("!")                   // Str::Str(const char*)
Str greeting = temp2 +  temp3;   // operator*(const Str&, const Str&)
```
(收起)
2011-07-09 21:34:49 回应

收藏
推荐

<前页 1 2 3 4 后页>

笔记是你写在书页留白边上的内容；是你阅读中的批注、摘抄及随感。

笔记必须是自己所写，不欢迎转载。摘抄原文的部分应该进行特殊标明。

>Accelerated C++