网络上以及与CDT Eclipse中使用外部文件资源有关的主题都在这里有信息：C / C ++和H文件位于文件系统中的其他位置。所有描述的方法都遵循两种方法：
我不确定在不添加第二种方法的情况下第一种方法是否总是足够的，但是似乎第二种在没有第一种方法的情况下构建良好。
我的问题是关于两者的比较。这些方法是打算类似使用还是在某些情况下首选每种方法？
每种方法在不应用另一种方法的情况下就足够了吗？
此论坛主题 https://www.eclipse.org/forums/index.php/t/1087314/建议，对于包含文件，第一种方法甚至可能还不够，因为构建设置仍应进行更新（第二种方法）以包含链接的H文件...那么可能与第一种方法无关？< / p>
答案 0 :(得分：0)
如果要编辑作为项目工作的一部分，外部文件通常会使用第一种方法，如果它们只是依赖项而没有使用，则通常使用第二种方法修改。
在技术层面上，不同之处在于，采用第一种方法时，文件将成为项目模型的一部分，例如在开放资源中显示为候选，而在第二种方法中则不会。另一个区别是，使用第一种方法时，文件是独立索引的，而使用第二种方法时，文件的索引仅是由项目中文件所包含的（例如，这些目录中的.cpp文件通常不会完全无法使用第二种方法建立索引。
更新：评论中问题的答案
第一种方法是否在所有情况下都足够，而无需更新Paths和Symbols属性？
否，如果项目中的文件使用与当前目录不相关的包含路径（因此不仅仅是同一目录中的#include "foo.h"，{{ 1}}在子目录中，等等，但在其他目录中是#include "../foo.h"，您仍然想在路径和符号中指定这些包含路径。
CDT的索引器确实具有“允许包含的启发式解析”选项（在“首选项”->“ C / C ++”->“索引器”中指定），该选项可以使您避免将路径添加到路径和符号，但请注意，（1）仅影响索引器，而不影响构建（如果您使用自己的makefile进行构建，可能会很好），以及（2）启发式，它并不完美，例如如果您在不同目录中具有相同名称的标头，则可能会感到困惑。为了获得最佳准确性，我建议取消选中“允许启发式解析包括”，并始终明确指定包含路径。
如果引用的文件按原样使用而无需修改，第二种方法本身是否足够？
我不明白为什么。