<字符串.h>与我自己的 String.h 冲突
我有一个项目在 g++ 中编译正常（我现在看不到版本），但现在在 xCode 上却编译不好。
我想我现在遇到了问题...我的项目中有一个 String.h 文件，似乎 xCode 编译器（即 gcc）正在尝试从 <<<> 添加我自己的字符串文件。 cstring >...我不确定，但看看这张图片
http://www.jode.com.br/Joe/xCode1.png
从它的外观来看，它包含我自己的文件而不是系统文件，我想知道......不应该 #include <文件>是一个系统包括吗？因为< > ？系统不应该在自己的路径中包含一个文件，而不是我的应用程序的原始路径吗？
正如我所说，我不确定这是否会发生，因为我这两天刚刚迁移到 osx...
我打算将我的类和文件名更改为不冲突，所以它会起作用，如果这确实是问题，但我想知道，应该有另一种方法来做到这一点，因为现在我的项目不是那么大，所以我可以在一段时间内做到这一点，但如果项目更大怎么办？更改所有包含和类名称将很困难...
任何帮助表示感谢
，谢谢，
乔纳森
I have a project that was compiling ok within g++(I can't see the version right now) and now on xCode it is not.
I think that I got the problem now... I have a String.h file in my project and it seems tha the xCode compiler(that is gcc) is trying to add my own string file from the < cstring >... I am not sure of it, but take a look at this picture
http://www.jode.com.br/Joe/xCode1.png
from what it looks like, it is including my own instead of the system file, I was wondering... shouldn't #include < file > be a system include? because of the < > ? and shouldn't the system include a file within its own path and not the original path of my application?
As I said, I am not sure if this is what happening because I am just migrating to osx these past 2 days...
I was going to change my class and file name to not conflict, so it would work, if this is really the problem, but I was wondering, there should be another way to do this, because now my project isn't that big so I can do this in some time, but what if the project was bigger? it would be dificult to change all includes and class names...
Any help is appreciated
Thanks,
Jonathan
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我有同样的问题，而且很难解决。花了我几个小时来修复/找出答案。
问题出在 xcode 的 headermap 上。解决方案 - 除了避免使用此类保留名称（一般来说这是一个好主意，但对于第三方库而言并不总是可行）之外，解决方案是添加
到用户定义的设置中。
向这些人致敬：
http://meidell.dk/archives/2010/05/ 08/xcode-header-map-files/
http://www .cocoabuilder.com/archive/xcode/262586-header-file-problem-sorry-to-bug-this-list.html
i had the same problem and it was hard to solve. took my hours to fix/find out.
the problem is the headermap of xcode. and the solution - besides avoiding those kind of reserved names, which is a good idea in general, but not always possible with third-party libs - is to add
to your user defined settings.
kudos to these guys:
http://meidell.dk/archives/2010/05/08/xcode-header-map-files/
http://www.cocoabuilder.com/archive/xcode/262586-header-file-problem-sorry-to-bug-this-list.html
使用与标准标头（例如 string.h）相同的名称命名标头，并简单地使用
#include包含它们会带来麻烦（大小写的差异）在某些平台上没有区别）。然而，正如您所说，在命名标头时很难尝试提前弄清楚它们是什么。因此，最简单的方法是将您的包含路径设置为标头所在子目录之外的一级目录，例如：
现在您不必担心 String.h 文件名是否冲突与您正在使用的库合而为一，除非它们碰巧也包含
Naming your headers with the same name as standard headers like string.h and including them simply with
#include <String.h>is asking for trouble (the difference in casing makes no difference on some platforms).As you said, however, it would be difficult to try to figure out what those are in advance when naming your headers. Thus, the easiest way to do this is to set to set your include path one directory level outside of a sub-directory in which your headers reside, ex:
Now you don't have to worry about whether the String.h file name conflicts with something in one the libraries you are using unless they happen to also be including
<Jonathan/String.h>which is unlikely. All decent third-party libraries do this as well. We don't include<function.hpp>in boost, for instance, but instead include<boost/function.hpp>. Same with GL/GL.h instead of simply GL.h. This practice avoids conflicts for the most part and you don't have to work around problems by renaming String.h to something like Text.h.是的，如果您使用
本地目录，则首先查找，并且
仅查找系统包含文件夹。
请注意仅在第一种情况下才使用单词first。这意味着每次包含时都不应访问您的本地版本（除非您已在 INCLUDE 指令中包含源路径）。
话虽如此，我的虚拟建议是用明确的名称重命名您的本地文件......
Yes, if you use
the local directory is looked first and
only the system include folders are looked.
Notice the word first only in the first case. This means that every time is included your local version should never be reached (unless you have included your source path within the INCLUDE directive).
Said that, my dummy suggestion is to rename your local file with an unambiguous name...
在 OSX 上，文件系统不区分大小写 - 因此 String.h 可能会遇到类似的冲突。字符串.h == 字符串.h
On OSX the filesystem is case insensitive - so String.h you can wind up with conflicts like that. String.h == string.h
它通过将名称从 String.h 更改为 Text.h 来工作
，但这没有意义，因为 std 库包含它自己的 string.h 而不是我的。
我的意思是，对于开发人员来说，考虑他不能使用哪些名称来创建文件是没有意义的，例如，假设我将 String.h 更改为 Text.h（我已经这样做了，我需要工作，并且这个不让我）广告不知何故我必须包含另一个模板库，其中包含一个名为 Text.h 的包含内容，我是否必须再次更改我的 text.h 或者不使用这个新库？应该有一个替代方案。
或者不应该这样？
感谢迄今为止的帮助，
乔纳森
it worked by changing the name from String.h to Text.h
but that makes no sense, since the std library is including it's own string.h and not mine.
I mean, makes no sense for a developer to create his files thinking of what names he can't use, for an instance, lets say I change my String.h to Text.h(I already did, I need to work and this is not letting me) ad somehow I had to include another templated library that has a include called Text.h, would I have to change my text.h again or not use this new library? there should be an alternative.
Or shouldn't it?
thanks for the help so far,
Jonathan
您遇到的两件事：
我建议的解决方法是将您的实用程序放入一个名称对于您的项目唯一的目录中，而不是重命名您的包含，并在您的包含指令中指定该目录。例如：
并确保 Josk/ 本身不在您的包含搜索路径中。这样，您就不会遇到尴尬的重命名问题，尽管您可能需要在项目中调整一些文件。您可能还需要编辑项目设置，以确保该实用程序目录的父目录位于您的包含路径中。
另一种尝试的可能性是，如果您看到顶级项目目录添加到项目的包含路径中，请将其删除。这应该可以防止在顶级项目目录中的项目被搜索系统包含。
最后，您还可以通过更改文件系统的大小写敏感性来避免这种特定情况下的此问题。不过，这可能会破坏一些 Mac 应用程序，因此在开始之前先研究一下问题，或者选择一个没有其他应用程序使用的卷。
Two things you're running into:
The workaround I would suggest, rather than renaming your includes, is to put your utilities into a directory whose name is unique for your project, and specify that directory in your include directive. For example:
and make sure
Josk/itself isn't in your include search path. This way you aren't stuck with an awkward rename, though you may have to shuffle some files around in your project. You may also need to edit your project settings to make sure the parent directory of that utility directory is in your include path.Another possibility to try is, if you see the top-level project directory added to your project's include path, remove it. This ought to keep items in your top-level project directory from being searched for system includes.
Finally, you may also be able to avoid this problem in this specific case by changing the case sensitivity of your file system. This can break some Mac applications, though, so research the issue before you embark on this – or pick a volume that nothing else is using.
这个问题已经有一些非常好的答案，但没有一个详细总结编译器通常如何搜索头文件；或者更准确地说，Xcode 将如何让编译器搜索它们。
当您包含用户头时，这些是引号之间的头文件 (
"...")，应用以下搜索顺序：请注意，使用完整的包含路径。因此，如果您的包含文件位于
foo/bar/file.c文件中，并且执行#include "subdir/header.h"，那么第一次查找将是 <代码>foo/bar/subdir/header.h。如果该文件不存在，编译器将迭代用户标头搜索路径。这些由构建设置
用户标头搜索路径提供（在配置文件中或在命令行上，其名为USER_HEADER_SEARCH_PATHS）。可以存在多个这样的路径，并且完整的包含路径会附加到每个路径，直到出现匹配为止。如果没有提供任何匹配项并且启用了构建设置
Use Header Maps(USE_HEADERMAP)，Xcode 会生成项目中所有头文件的映射文件并搜索此映射文件查找与所包含文件的名称相匹配的条目。在这种情况下，路径是无关紧要的，因为它也只匹配文件名。对于系统标头，尖括号 (
<...>) 之间的系统标头，仅来自构建设置系统标头搜索路径(SYSTEM_HEADER_SEARCH_PATHS< /code>) 被搜索。但是，如果启用了构建设置
始终搜索用户路径(ALWAYS_SEARCH_USER_PATHS)，则还会搜索用户搜索路径以查找系统标头包含。这允许您使用您自己的同名用户标头覆盖系统标头。但请注意，Xcode 已弃用此操作，不应再这样做。如果您的文件系统不区分大小写（macOS 上默认为大小写），则大小写在所有搜索过程中都不起作用。
如果您希望最大程度地控制要包含的文件，请禁用标头映射并始终包含与执行包含的文件相关的路径（也可以使用“..”）。这可以避免任何歧义。
This question already has some very good answers, yet none of them summarizes in all detail how the compiler will search for header files in general; or more precisely, how Xcode will make the compiler search for them.
When you include a user header, those are header files between quotes (
"..."), the following search order applies:Note that the full include path is used. So if your include is in the file
foo/bar/file.cand you do a#include "subdir/header.h", then the first lookup will befoo/bar/subdir/header.h.If that file doesn't exist, the compiler iterates the user header search paths. Those are provided by the build setting
User Header Search Path(within config files or on command line it's namedUSER_HEADER_SEARCH_PATHS). Multiple such path can exist and again, the full include path is attached to each of them until there's a match.If provides no match either and the build setting
Use Header Maps(USE_HEADERMAP) is enabled, Xcode generates a map file of all your header files in the project and searches this map file for an entry that matches the name of the included file. In that case the path is irrelevant, as it would also match just the name of the file.For system headers, those between spiky braces (
<...>), only the search paths from the build settingSystem Header Search Paths(SYSTEM_HEADER_SEARCH_PATHS) are searched.However if the build setting
Always Search User Paths(ALWAYS_SEARCH_USER_PATHS) is enabled, the user search paths are also searched for system header includes. This allows you to override a system header with your own user header of the same name. Note however, that this is deprecated by Xcode and shouldn't be done anymore.If your file system is case-insensitive, default on macOS, then case will play no role during all searches.
If you want maximum control over which file is being included, disable header maps and always include with a path relative to the file performing the include (you may use ".." as well). This avoids any ambiguity.