/********************************************\
| 欢迎转载, 但请保留作者姓名和原文链接, 祝您进步并共勉! |
\********************************************/
C++对象模型(9) - 3.1 The Binding of a Data Member
作者: Jerry Cat
时间: 2006/11/15
链接:
http://www.cppblog.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++程序员发明了俩防范写法(至今还有人用):
(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.(数据成员定义还是要放在最前面)
posted on 2006-11-15 17:04
Jerry Cat 阅读(443)
评论(0) 编辑 收藏 引用