.h 文件有什么意义？
我知道 .h 文件应该包含：
- 类声明、
- 函数原型
- 和外部变量（对于全局变量）
但是将其设为 .h 文件有什么意义吗？ 我尝试将 .h 文件重命名为 .c 文件，它仍然有效。
我们可以将文件命名为任何名称，但我们选择将其命名为 .h 文件。
我对吗？
I know that .h file is supposed to have:
- class declarations,
- function prototypes,
- and extern variables (for global variables)
But is there some significance of making it a .h file?
I tried renaming my .h file to a .c file and it still works.
We can name our file to be anything, but we choose to name it as a .h file.
Am I correct?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
虽然确切的命名是一种约定，但头文件和源文件的处理之间的区别并不是——头文件不编译成目标文件，而是包含在源文件中（共同形成翻译单元） 。此外，它们可能包含在多个源文件中，以便多个源文件共享相同的定义。这些文件的语义可能是相同的，但编译器会因为它们的用途而以不同的方式对待它们。
就命名而言，我个人至少见过这些 -
*.h、*.H（呃）、*.hpp、*.hxx、*.hh、*.inl（对于普通标头，而不仅仅是内联代码 - 恶心）。通常伴随着匹配的目标文件扩展名。请注意，标准库头没有扩展名——例如字符串。
因此，这完全取决于品味和惯例 - 您将
#include包含在内。While the exact naming is a convention, the difference between the treatment of header files and source files is not -- header files are not compiled into object files, but included in source files (collectively forming translation units). Moreover they may be included in multiple source files, so that multiple source files share the same definitions. The semantics of the files may be the same, but the compiler treats them differently, because of their usage.
As far as naming goes, personally I've seen at least these --
*.h,*.H(ugh),*.hpp,*.hxx,*.hh,*.inl(for normal headers, not just inlined code -- yuck). Usually accompanied by a matching object file extension.Note that standard library headers don't have an extension -- e.g. string.
So it's all a matter of taste and conventions -- what you will
#include, that will be included.使用 .h 来命名头文件只是一种约定。您还会看到（可能在类 Unix 平台上）：
就个人而言，我强烈建议坚持使用 .h。特别是，不要使用 .H，否则如果您需要移植到不区分大小写的文件系统，您将陷入痛苦的境地。
The use of .h to name header files is just a convention. You will also see (probably on Unix-like platforms):
Personally, I'd strongly advise sticking with .h. Particularly, don't use .H, or you will be in a world of pain if you ever need to port to case-insensitive file system.
这只是一个约定 - “h”代表“标题”。但与大多数惯例一样，您需要有充分的理由来违反它。
It's just a convention - the "h" stands for "header". Like most conventions though, you would need to have a very good reason to contravene it.
文件名及其扩展名对编译器来说毫无意义。您可以将它们命名为
h.main或其他任何名称。请记住保持包含完整。The name of a file, as well as its extension, means absolutely nothing to compiler. You can name them
h.mainor anything else. Just remember to keep includes intact.我认为扩展之前针对类似 Visual Studio 的 IDE 的答案可能是值得的。
为简单起见，您应该使用编程 IDE 识别的命名约定。它最重要的规则是告诉它对哪些文件使用哪个编译器。例如，.c 将被编译为 C 代码，.cpp 将被编译为 C++，.cs 将被编译为 C#，.rc 将被资源编译器编译等等。
将某些内容命名为 .h 或标准编译器选择规则之一未涵盖的任何其他内容，可以防止文件自行编译，而这正是您想要的头文件。如果您尝试过在 Visual Studio 中将标头重命名为 .c 进行测试，那么除非您明确将其从构建中排除，否则它会为您编译。
您的 IDE 中可能还有其他可用的工具 - 例如，用于生成类图、进行源代码分析等的工具，并且这些工具也可能具有您应该保持兼容的文件命名约定。
I thought it might be worthwhile to expand the previous answer for Visual Studio-like IDEs.
For simplicity you should use naming conventions that are recognized by your programming IDE. The most important rules it has are the ones that tell it what compiler to use for which files. For example, .c will be compiled as C code, .cpp as C++, .cs as C#, .rc by the resource compiler and so on.
Naming something .h, or anything else not covered by one of the standard compiler selection rules, prevents a file being compiled on its own, which is what you want for header files. If you had tried your test of renaming your header to .c in Visual Studio, it would have been compiled for you unless you explicitly excluded it from the build.
There may be other tools available in your IDE - for example, tools to generate class diagrams, do source code analysis etc., and these may also have file naming conventions that you should stay compatible with.
我们的大型开发项目
#include来自 cc 文件的 cc 文件，用于具有数百种方法的类。我不同意，但也有理由。Our big development projects
#includecc files from cc file for classes with hundreds of methods. I didn't agree with it, but there were reasons.您编译 .h 和 .cpp 并将其链接到 .obj。然后，您将 .h 和 .obj （您的部分）提供给您的合作伙伴（您的合作伙伴不了解实际代码），最后链接器将所有 obj 合并为可执行文件。 .h 是一个众所周知的指示符，用于告诉程序员该文件不包含定义。如果全世界都接受的话我们可以使用 .xyz :-)
you compile and link your .h and .cpp to .obj. Then you give .h and .obj (your part) to your partner (your partner have no knowledge about the actual code), finally linker merge all the obj to a executable. .h is an well-known indicator to tell programmer that this file does not contain definition. we can use .xyz if the whole world accept it :-)
此外，当你有一个 makefile 时，可以这样说：将所有以 .c 结尾的文件编译为目标文件，而不是单独指定每个文件。现在，如果您开始使用 .c 扩展名命名头文件，那么 make 系统可能会尝试将头文件编译成目标文件...
因此，拥有单独的 *.h 和 *.c 文件可以使所有内容保持清晰和清晰，不仅对于程序员来说，但对于 make 系统、编译器和链接器也同样重要。
Moreover, when you have a makefile, its possible to say something like, compile all files ending in .c to object files, rather than specifying each separately. Now if you start naming you header files with .c extensions, then the make system may try to compile the header files into object files...
So to have separate *.h and *.c files keeps everything distinct and clear, not only for the programmer, but just as crucially for the make system, compiler and linker.