|
文章开始提出了一段示例代码，并讨论了返回哪个x的问题。然后 a) 给出了我们普遍认为正确的回答，并肯定了这个想法； b) 提醒大家，这在以前的编译器实现中，并非正确。 在早期的实现中，首先绑定的是“全局变量x”。因为该class中的x的声明尚未可见。由此导致的就是“防御性编程风格”。总结起来，具体做法有两种。 c) 将所有的data member的声明提前； d) 将内联函数的实现移至class的声明之外。 对于第一点，我们容易理解。因为变量的声明中，较晚的声明总是可以覆盖之前的。我想说下自己对于第二点的理解。 书中将此称为“member rewriting rule”。基本意义是，内联函数的实体，在整个class未被声明完全时，是不会被evaluate的（书中将evaluated翻译为评估求值，我个人觉得不是很恰当，我也没有想出什么更好的翻译，还是用英文表意更准确一点；还有后文的resolve，翻译为“决议”也不是很通顺，觉得“解析”更好）。也即是说，内联函数内的数据成员绑定也是在要class声明之后进行的。这个意义被C++Standard提炼为“member scope resolution rules”（成员作用域解析规则）。这是书里的说法。在程序中的效果是，如果内联函数在类声明后立即展开的话，它就会被evaluate。 当然上述规则也有失效的时候，比如，成员函数的参数列表。他们遵循的规则是“第一次遇到时，被适当的决议完成”。之后作者说，“extern和nested type names之间的非直觉绑定还是会发生”。目测这句话的意思是，此时会将“nested type names”解析为extern类型。这可以用书中的实例代码来引证。 在length的定义出现之前，它被使用了两次。结果是length被认为是extern类型，符合上述分析。而之后，length的声明出现时，前述解析会被否定。原文提到，“C++ Standard把稍早的绑定标示为非法”。此句意义不甚明确。标示为非法是什么意思？编译不通过，还是编译通过，但是增加了编译的开销（因为先认为length是一种类型，但是后来的声明使得原来的判定是错误的，而要重新解析）。对于这种情况，作者建议使用防御性编程风格，这也就是说建议，将data member的声明提前到使用之前。从这一点看，是不是可以认为C语言的编程方式更为科学？ |
3.1 Data Member的绑定