/********************************************\
|????歡迎轉載, 但請保留作者姓名和原文鏈接, 祝您進步并共勉!???? |
\********************************************/

C++對象模型(9) - 3.1 The Binding of a Data Member

作者: Jerry Cat
時間: 2006/11/15
鏈接:? http://www.shnenglu.com/jerysun0818/archive/2006/11/15/15186.html

3.1 The Binding of a Data Member

Consider the following program fragment:.

// A third party foo.h header file
// pulled in from somewhere
extern float x;

// the programmer's Point3d.h file
class Point3d
{
public:
?? Point3d( float, float, float );
?? // question:? which x is returned and set?
?? float X() const { return x; }
?? void X( float new_x ) const { x = new_x; }
?? // ...
private:
?? float x, y, z;
};
If I were to ask which x the Point3d member X() returns—the class instance or the extern instance—everyone today would answer the class instance, and everyone would be right. Most everyone, however, would probably be surprised to learn that this answer was not always correct.

早期的C++將其解析為X()函數引用的是全局數據. 所以早期的C++程序員發(fā)明了倆防范寫法(至今還有人用):
(1). Placing all data members first in the class declaration to ensure the right binding:

class Point3d
{
?? // defensive programming style #1
?? // place all data first ...
?? float x, y, z;
public:
?? float X() const { return x; }
?? // ... etc. ...
};

(2). Placing all inline functions, regardless of their size, outside the class declaration:

class Point3d
{
public:
?? // defensive programming style #2
?? // place all inlines outside the class
?? Point3d();
?? float X() const;
?? void X( float ) const;
?? // ... etc. ...
};
inline float
Point3d::
X() const
{
?? return x;
}

// ... etc. ...

extern int x;

class Point3d
{
public:
?? ...
?? // analysis of function body delayed until
?? // closing brace of class declaration seen.
?? float X() const { return x; }
?? ...
private:
?? float x;
?? ...
};

// in effect, analysis is done here
the analysis of the member function's body is delayed until the entire class declaration is seen. Thus the binding of a data member within the body of an inline member function does not occur until after the entire class declaration is seen.

但是This is not true of the argument list of the member function, however. Names within the argument list are still resolved in place at the point they are first encountered. Nonintuitive bindings between extern and nested type names, therefore, can still occur. In the following code fragment, for example, the type of length in both member function signatures resolves to that of the global typedef—that is, to int. When the subsequent declaration of the nested typedef of length is encountered, the Standard requires that the earlier bindings be flagged as illegal:

typedef int length;

class Point3d
{
public:
?? // oops: length resolves to global
?? // ok: _val resolves to Point3d::_val
?? mumble( length val ) { _val = val; }
?? length mumble() { return _val; }
?? // ...

private:
?? // length must be seen before its first
?? // reference within the class.? This
?? // declaration makes the prior reference illegal.
?? typedef float length;
?? length _val;
?? // ...
};
This aspect of the language still requires the general defensive programming style of always placing nested type declarations at the beginning of the class. In our example, placing the nested typedef defining length above any of its uses within the class corrects the nonintuitive binding.(數據成員定義還是要放在最前面)