外部依赖性在这里（其实很容易被忽略）！但是由它可以看到许多隐藏的东西！

它能说明什么问题？

看右边程序源代码中直接使用system("pause");

而学过C语言的小伙伴们应该都晓得，要使用这个函数，必须要引入stdlib.h，即：

#include

但是这里为什么不引入，就可以使用了呢？

其实并没有违背“函数调用时候必须要有函数体的支撑”这个客观规律。只是它被隐藏了。就在这里：

不感觉奇怪吗？已经被引入进来了！但是自己并没有包含它啊，这就是“文件依赖”而导致的结果。

其实写不同的程序会用到不同的函数，也就需要包含不同的文件。但此时，如果该文件中的代码又需要其他文件先被加载，就产生了依赖（这在linux中编译软件的时候经常看到，那是软件依赖，因此才有yum安装软件方式的出现）

我们先看看不同程序的依赖文件列表：

1：

这里不引入任何文件，所以那个“外部依赖项”目录是空的。

现在改为：

编译之后，可以看到依赖目录里有stdio.h，同时还牵扯出要让stdio.h里面的代码正常运行的其他依赖文件。所以有一大堆。

继续改为：

可见，你手工包含的stdio.h,stdlib.h都被引入了，同时还引入了其他依赖文件。

再改为：

打开之后看：

可见，文件名它可以取.h后缀的，也可以取没有任何后缀的，都是个文件，它自己打的开就行，同时也是和C语言里面的头文件区别开来，能一眼就知道是C++特有特性的文件。

可见，虽然你只引入iostream文件，但是它需要其他的依赖文件，这样就把stdio.h，stdlib.h给引入进来了。

所以你可以直接使用system("pause");

试着打开iostream这个文件：

可见，这个文件里面确实包含了istream，才引进来。

同时可以看到string.h也被包含进来了，就是C语言里面的那种处理字符串的用法。所以后续C++里不想用这个string.h里面的东西了，就需要另外引入string文件，才能使用string类型（因为该string文件没有被包含进来，所以才要自己包含）。

注意：

由于文件之间的包含和依赖很多很细，还随机穿插，所以列出了个列表出来方便查看，它其实没有这个义务的，所以让你在编译之后才列出了给你看都已经是好的了，所以要求不要太高。所以：记住在编译之后再看。如果没列出了，重新关闭软件，重新打开编译程序，就可以看到了。为什么会这样？因为它只有编译的时候才知道要依赖什么，而当时已经把相关的代码拿走放到编译结果的可执行文件去了，这个软件的这个地方只是给你个回馈信息，所以滞后甚至不给你列出了给你看，也是可以的。所以如果没列出了，那就重新关闭软件，重新编译运行一下就看到了（反正我测试的时候是这种效果）。