Question

我正在构建一种可以编译为C或C ++的小语言，我还没有决定，但是我遇到了关于#include关键字的两难问题。

我的语言将附带一个标准库，该库将被合并到该语言中，并且可以像C或C ++那样使用#include <string>等标准包含。

我的编译器可以自动区分用户包含和标准库包含的区别，但我的问题在于GCC编译器如何使用-I标志。

让我们以Java为例。其中一个默认包（文件夹）称为java.util。如果我尝试在我的项目中创建自己的名为java.util的文件夹，我会收到错误：

java.util包与另一个模块可访问的包冲突：java.base

默认包含它。

我希望在C ++中做同样的事情，但我担心用户可能（假设）做一个相对路径包含并导致冲突。

例如，我使用这样的标志：-I ../some/folder。

然而，用户只需键入#include "../some/folder"即可访问相同的内容。有什么方法可以限制这个，就像问题的标题所暗示的那样，＆＃34;保护＆＃34; 该文件夹不会被调用吗？

此外，如果该文件夹中有一个名为test.h的文件，并且用户决定在本地创建自己的文件test.h并将其包含在内。冲突将如何发生？它会在包含的via上选择本地文件夹吗？标志？

基本实现的示例如下:(一般语法，没有特定语言）

boolean userDefine = false;
string defineName = "foo";

// Do something to determine if <> define or "" define.

if (userDefine) {
    // Returns #include "foo"
    return "#include \"" + defineName + "\"";
} else {
    // Returns #include "stdlib/foo"
    return "#include \"stdlib/" + defineName + "\"";
}

但话又说回来，用户可以包含该文件夹，使其满足第一个条件并仍然可以访问。

Answer 1

将C #include文件放在C ++源文件的最开头作为第一个业务顺序，这几乎是标准做法。

当然，#include可以出现在C ++源文件的任何地方，并且在某些情况下会发生这种情况但是，如果你要从github获取一些随机的C ++源代码，很可能所有的{ {1}}文件将位于文件的开头。

所以，你所要做的就是安排你的图书馆的#include始终在开头，并在你的头文件中使用标准的#include警卫。然后，无论使用何种路径，随后手动包含它们都不会产生任何影响。

当然，这不会阻止任何人手动#ifndef/#define你的警卫，制造一些混乱。然而，C ++从来没有因为可靠地防止你自己摔倒而声名远扬，并且在可预见的未来不太可能获得这种声誉;所以呢？实际上，大多数编译器实现了#undef，这可能是一种稍微好一点的自我预防方法......

保护某些包含位置

1 个答案: