[翻译] Effective C++, 3rd Edition, Item 41: 理解 implicit interfaces(隐式接口)和 compile-time polymorphism(编译期多态)

本文围绕C++中显式接口、隐式接口,以及执行期多态、编译期多态展开。面向对象编程以显式接口和执行期多态为中心,而模板和泛型编程更注重隐式接口和编译期多态。文中通过示例详细分析了两者区别,强调接口和多态在类与模板中都受编译检查。

Item 41: 理解 implicit interfaces(隐式接口)和 compile-time polymorphism(编译期多态)

作者:Scott Meyers

译者:fatalerror99 (iTePub's Nirvana)

发布:http://blog.youkuaiyun.com/fatalerror99/

Object-Oriented Programming(面向对象编程)的世界是围绕着 explicit interfaces(显式接口)和 runtime polymorphism(执行期多态)为中心的。例如,给出下面这个(没有什么意义的)class(类),

class Widget {
public:
  Widget();
  virtual ~Widget();
  virtual std::size_t size() const;
  virtual void normalize();
  void swap(Widget& other);                 // see Item 25

  ...
};

以及这个(同样没有什么意义的)function(函数),

void doProcessing(Widget& w)
{
  if (w.size() > 10 && w != someNastyWidget) {
      Widget temp(w);
      temp.normalize();
      temp.swap(w);
  }
}

我们可以这样谈论 doProcessing 中的 w

  • 因为 w 被声明成类型 Widget,则 w 必须支持 Widget interface(接口)。我们可以在源代码中找到这个 interface(接口)(例如,Widget.h 文件)以看清楚它是什么样子的,所以我们称其为一个 explicit interface(显式接口)——它在源代码中显式可见。
  • 因为 Widget 的一些 member functions(成员函数)是虚拟的,w 对这些函数的调用就表现为 runtime polymorphism(执行期多态):被调用的特定函数在执行期基于 w 的 dynamic type(动态类型)来确定(参见 Item 37)。

templates(模板)和 generic programming(泛型编程)的世界是根本不同的。在那个世界,explicit interfaces(显式接口)和 runtime polymorphism(执行期多态)继续存在,但是它们不那么重要了。反而,implicit interfaces(隐式接口)和 compile-time polymorphism(编译期多态)移到了前台。为了了解这是怎样一种情况,看一下当我们把 doProcessing 从一个 function(函数)变成一个 function template(函数模板)时会发生什么:

template<typename T>
void doProcessing(T& w)
{
  if (w.size() > 10 && w != someNastyWidget) {
     T temp(w);
     temp.normalize();
     temp.swap(w);
  }
}

现在我们可以如何谈论 doProcessing 中的 w 呢?

  • w 必须支持的 interface(接口)是通过 template(模板)中在 w 身上所执行的操作确定的。在本例中,它显现为 w 的类型 (T) 必须支持 sizenormalizeswap member functions(成员函数);copy construction(拷贝构造函数)(用于创建 temp);以及对不等于的比较(用于和 someNastyWidget 之间的比较)。我们将在以后看到这并不很精确,但是对于现在来说它已经足够正确了。重要的是这一系列为了模板能够编译必须合法的表达式就是 T 必须支持的 implicit interface(隐式接口)。
  • 对诸如 operator>operator!= 这样的涉及 w 的函数的调用可能伴随 instantiating templates(实例化模板)以使这些调用成功。这样的 instantiation(实例化)发生在编译期间。因为用不同的 template parameters(模板参数)实例化 function templates(函数模板)导致不同的函数被调用,因此以 compile-time polymorphism(编译期多态)闻名。

即使你从没有使用过模板,你也应该熟悉 runtime(运行期)和 compile-time polymorphism(编译期多态)之间的区别,因为它类似于确定一系列重载函数中哪一个应该被调用的过程(这个发生在编译期)和 virtual function(虚拟函数)调用的 dynamic binding(动态绑定)(这个发生在运行期)之间的区别。explicit(显式)和 implicit interfaces(隐式接口)之间的区别是与 templates(模板)有关的新内容,需要对他进行近距离的考察。

一个 explicit interface(显式接口)一般由 function signatures(函数识别特征)组成,也就是说,函数名,参数类型,返回类型,等等。例如,Widget class(类)的 public interface(公有接口),

class Widget {
public:
  Widget();
  virtual ~Widget();
  virtual std::size_t size() const;
  virtual void normalize();
  void swap(Widget& other);
};

由一个 constructor(构造函数),一个 destructor(析构函数),以及函数 sizenormalizeswap 组成,再加上 parameter types(参数类型),return types(返回类型)和这些函数的 constnesses(常量性)。(它也包括 compiler-generated(编译器生成)的 copy constructor(拷贝构造函数)和 copy assignment operator(拷贝赋值运算符)——参见 Item 5。)它还可能包含 typedefs,还有,如果你胆大包天敢于违背 Item 22 的让 data members(数据成员)private(私有)的建议,那就包括 data members(数据成员),虽然在当前情况下,它不是。

一个 implicit interface(隐式接口)有很大不同。它不是基于 function signatures(函数识别特征)的。它是由 valid expressions(合法表达式)组成的。再看一下在 doProcessing template 开始处的条件:

template<typename T>
void doProcessing(T& w)
{
  if (w.size() > 10 && w != someNastyWidget) {
  ...

对于 Tw 的类型)的 implicit interface(隐式接口)看起来有如下这些约束:

  • 它必须提供一个名为 size 的返回一个数值的 member function(成员函数)。
  • 它必须支持一个用于比较两个类型 T 的对象的 operator!= 函数。(这里,我们假定 someNastyWidget 的类型为 T。)

由于 operator overloading(运算符重载)的可能性,这两个约束都不必满足。是的,T 必须支持一个 size member function(成员函数),可是值得一提的是这个函数可以是从一个 base class(基类)继承来的。但是这个 member function(成员函数)不必返回一个整数类型。它甚至不必返回一个数值类型。对于这种情况,它甚至不必返回一个定义了 operator> 的类型!它要做的全部就是返回某种类型 X 的一个 object(对象),存在一个可以由一个类型 X 的 object(对象)和一个 int(因为 10 为 int 类型)来调用的 operator>。这个 operator> 不一定非要取得一个类型 X 的参数,因为只要存在一个从类型 X 的 objects(对象)到类型 Y 的 objects(对象)的 implicit conversion(隐式转型),它只取得一个类型 Y 的参数也是可以的!

类似地,T 支持 operator!= 也是没有必要的,因为正像 operator!= 取得一个类型 X 的 objects(对象)和一个类型 Y 的 objects(对象)是可接受的一样。只要 T 能转型为 X,而 someNastyWidget 的类型能够转型为 Y,对 operator!= 的调用就是合法的。

(旁注:此处的分析没有考虑 operator&& 被重载的可能性,这会将上面的表达式的含义从逻辑与转换到某些大概完全不同的东西。)

第一次考虑 implicit interfaces(隐式接口)的时候,大多数人都会头疼,但是他们真的不需要阿司匹林。implicit interfaces(隐式接口)简单地由一套 valid expressions(合法表达式)构成。这些表达式自身看起来可能很复杂,但是它们施加的约束通常是简单易懂的。例如,给出这个条件,

if (w.size() > 10 && w != someNastyWidget) ...

关于 functions sizeoperator>operator&&operator!= 上的约束很难说出更多的东西,但是要识别出整个表达式的约束是非常简单的。一个 if 语句的条件部分必须是一个 boolean expression(布尔表达式),所以不管 "w.size() > 10 && w != someNastyWidget" 所产生的精确类型是哪一种,它必须与 bool 相容。这就是 template(模板)doProcessing 施加于它的 type parameter(类型参数)T 之上的 implicit interface(隐式接口)的一部分。doProcessing 必需的 interface(接口)的其余部分是 copy constructor(拷贝构造函数),normalizeswap 的调用对于类型 T 的 objects(对象)来说必须是合法的。

implicit interface(隐式接口)对 template(模板)的 parameters(参数)施加的影响正像 explicit interfaces(显式接口)对一个 class(类)的 objects(对象)施加的影响,而且这两者都在编译期间被检查。正像你不能用与它的 class(类)提供的 explicit interface(显式接口)矛盾的方法使用 object(对象)(代码无法编译)一样,除非一个 object(对象)支持 template(模板)所必需的 implicit interface(隐式接口),否则你就不能在一个 template(模板)中试图使用这个 object(对象)(代码还是无法编译)。

Things to Remember

  • classes(类)和 templates(模板)都支持 interfaces(接口)和 polymorphism(多态)。
  • 对于 classes(类),interfaces(接口)是 explicit(显式)的并以 function signatures(函数识别特征)为中心。polymorphism(多态性)通过 virtual functions(虚拟函数)出现在运行期。
  • 对于 template parameters(模板参数),interfaces(接口)是 implicit(隐式)的并基于 valid expressions(合法表达式)。polymorphism(多态性)通过 template instantiation(模板实例化)和 function overloading resolution(函数重载解析)出现在编译期。
<think>我们正在处理一个C语言编译警告:incompatible implicit declaration of built-in function &#39;exit&#39; 根据引用[3]的内容,这个警告是因为没有包含相应的头文件。exit函数在stdlib.h中声明,因此需要包含这个头文件。 用户的问题是关于xbuplot.c的编译警告,所以我们只需要在源代码中添加#include <stdlib.h>即可。 但是,我们还需要注意:根据引用[1][2],这个警告是因为编译器在声明(即没有看到函数原型)的情况下使用了内置函数(built-in function),而声明的函数签名与内置函数不兼容。解决方法是显包含正确的头文件。 因此,步骤: 1. 找到xbuplot.c源文件。 2. 在文件开头(或者在使用exit函数之前)添加#include <stdlib.h>。 如果已经包含了该头文件,那么可能是头文件包含顺序的问题,确保在使用exit之前包含了stdlib.h。 另外,引用[3]提到为什么是warning而不是error:因为C语言允许声明函数,但声明可能不符合实际函数,所以编译器给出警告。 所以,解决方案就是包含stdlib.h头文件。 注意:如果程序中还使用了其他函数,如printf(需要stdio.h)、malloc(需要stdlib.h)等,也要确保包含了相应的头文件。 下面我们假设用户没有包含stdlib.h,因此我们建议添加。</think>要解决 `xbuplot.c` 编译时出现的警告 `incompatible implicit declaration of built-in function &#39;exit&#39;`,请按照以下步骤操作: ### 🔧 解决方案 1. **添加头文件包含** 在源文件开头添加标准库头文件: ```c #include <stdlib.h> // 包含 exit() 函数声明 ``` 2. **检查所有函数调用** 确保所有使用 `exit()` 的地方都位于 `#include <stdlib.h>` 之后: ```c #include <stdlib.h> // 必须在调用 exit() 之前 int main() { if (error) { exit(EXIT_FAILURE); // 正确使用 } // ... } ``` ### ⚠️ 警告原因分析 1. **声明问题** 当编译器遇到未声明的函数时,会按默认规则声明为: ```c int exit(); // 假设返回 int 且参数类型未知 ``` 但实际 `exit()` 在库中的正确定义是: ```c _Noreturn void exit(int status); // 实际原型 ``` 2. **不兼容风险** | 特性 | 声明 | 实际定义 | 冲突点 | |------------|------------------|-------------------|---------------| | 返回类型 | `int` | `void` | 类型不匹配 | | 参数类型 | 任意参数 | `int` | 参数检查失败 | | 函数属性 | 普通函数 | `_Noreturn` | 控制流分析错误 | 3. **编译器行为** 编译器将其视为警告而非错误: - 历史原因:C89 允许函数声明 - 兼容性考虑:旧代码可能依赖此特性 - 实际风险:在 64 位系统中可能导致栈损坏(status 参数截断) ### 🛠️ 进阶处理 1. **替换为安全版本** 推荐使用更安全的终止函数: ```c #include <stdlib.h> // ... if (critical_error) { fprintf(stderr, "致命错误: 代码%d\n", errcode); exit(EXIT_FAILURE); // 代替 exit(1) } ``` 2. **编译选项强化** 在 Makefile 中添加严格检查选项: ```makefile CFLAGS += -Werror=implicit-function-declaration # 将警告转为错误 CFLAGS += -std=c11 # 使用现代C标准 ``` ### 📚 最佳实践 1. **头文件包含顺序** 按以下顺序组织头文件: ```c #include "xbuplot_local.h" // 本地头文件 #include <stdlib.h> // 标准库 #include <math.h> // 其他库 ``` 2. **静态分析检查** 使用 Clang 静态分析器: ```bash clang --analyze -Xanalyzer -analyzer-output=text xbuplot.c ``` > 实际案例表明,未修复的 `exit()` 声明在 ARM 架构上会导致栈指针错误[^1],在 x64 系统可能造成退出状态码截断[^2]。 ### 验证修复 ```bash # 修复后重新编译 gcc -Wall -Wextra xbuplot.c -o xbuplot # 应不再出现警告 ```
评论 4
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值