今天在Debian1系统上使用NetBeans2写C++程序，在键入#include时IDE有#include_next的提示。这个预编译指令以前没有接触过，本篇文章做个总结。

[1] 一种Linux发行版。

[2] 一种支持多种语言开发的集成开发环境。

是标准C/C++扩展吗？

不是。是GNU的扩展，所以如果你使用Windows 的MSVC的话是使用不了#include_next的。

用途是什么？

GCC的文档2.7节Wrapper Headers解释得很清楚，下面的内容仅仅是这一节的翻译：

有时需要调整系统提供的头文件的内容而不编辑是很必要的，如，GCC的fixincludes操作提供了这种功能。

一种方式是新建一个同名的头文件，并将其排在原有头文件的搜索路径之前。如果你愿意彻底替换掉老的头文件的话，这种方式是没问题的。但是，如果你要从新的头文件里访问这个老的头文件呢?你不能简单的使用#include引入老的头文件。这样的话，会从搜索路径里再次找到新的头文件(因为新的头文件在搜索路径里排在老的头文件之前)。如果你的头文件没有使用多头文件引入保护，会出现无限递归并且导致严重的错误。

当然，你可以使用绝对路径引入老的头文件：#include "/usr/include/old-header.h"这种方式是可行的，但不够简洁;若系统头文件移动，你将不得不修改新的头文件里的老的头文件的路径。在C标准里没有办法解决这个问题，但你可以使用GNU的#include_next扩展。它意味者：使用这个名字引入下一个文件。这个指令跟#include工作方式类似，除了对指定文件的搜索方式上：在一个目录下找到了当前的文件，这时不会停止查找，它开始在后续的头文件目录列表里继续查找`#include_next所引入的文件。举例来说，你指定了-I /usr/local/include，并且待搜索的目录列表包含/usr/include，这两个目录里都包含signal.h文件。普通的#include能找到/usr/local/include里的文件。若那个文件里含有#include_next，它开始在所在目录之后查找，并找到/usr/include里的signal.h。#include_next不区分<file>和"file"这两种方式的引入，它也不检查当前文件和所引入的文件是否同名。它只是简单地在当前所找到文件的目录之后查找include_next所引入的文件。include_next的使用会导致较大的混淆。我们建议只是在没有其他方式可用的情况下使用它。特别不能在某个具体程序所拥有的头文件里使用它;类似于fixincludes，它应该仅仅用于全局的修正。

本文内容转载自网络，本着分享与传播的原则，版权归原作者所有，如有侵权请联系我们进行删除。