我正在构建一种可以编译为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"即可访问相同的内容。有什么方法可以限制这一点，并且像问题的标题所暗示的那样，"保护">文件夹不被这样调用？
此外，如果该文件夹中有一个名为test.h的文件，并且用户决定在本地创建自己的名为test.h的文件并将其包含在内。冲突将如何发生？它会在包含的通孔上选择本地文件夹吗？标志？
基本实现的示例如下：(通用语法，无特定语言)
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 + """;
}
但话又说回来，用户可以包含文件夹，以便它满足第一个条件并仍然获得访问权限。
将任何#include文件放在C++源文件的开头几乎是标准做法，作为首要任务。
当然，#include可以出现在C++源文件中的任何位置，在某些情况下会发生这种情况，但是，如果您要从 github 获取一些随机C++源，则很有可能所有#include文件都将位于文件的开头。
因此，您所要做的就是安排库的#include始终位于开头，并在头文件中使用标准#ifndef/#define保护。然后，无论使用什么路径，随后手动包含它们都不会产生任何效果。
当然，这不会阻止任何人手动#undef你的警卫，制造一些混乱。然而，C++从来没有可靠地防止你搬起石头砸自己的脚的名声，并且在可预见的未来不太可能赢得这种声誉;那又怎样？实际上，大多数编译器都实现了#pragma once，这可能是一种稍微好一点的脚自拍预防方法......