C++ 代码文件扩展名？ .cc和.cpp有什么区别[关闭]答案

【问题标题】：C++ code file extension? What is the difference between .cc and .cpp [closed]C++ 代码文件扩展名？ .cc和.cpp有什么区别[关闭]
【发布时间】：2010-12-05 10:18:36
【问题描述】：

我看到 C++ 代码同时保存为 .cc 和 .cpp 文件。两者有区别吗？

Google style guide 似乎暗示了.cc，但没有提供任何解释。

我主要关心Linux系统上的程序。

【问题讨论】：

结论没关系。 可能的起源 cc = C with classes, cpp = C plus plus
对clang++很重要。当你给它一个名称以 .h 结尾的 C++ 头文件时，clang++ 会警告你。
另一个比较关心的工具是emacs。使用干净的 .emacs 配置，打开（用 emacs 术语“查找”）一个 .h 文件会激活 c-mode，而不是 c++-mode。当然，您可以将 emacs 配置为执行其他操作（就像 emacs 中的所有内容一样），但我的观点是 c-mode 是开箱即用的默认设置。
lint 关心，.C 是 C++，.c 是 C，完全不了解 .cc 或 .cpp。至少在 AIX 6.1 上。
回答“没关系”并没有真正的帮助。这个问题是完全相关的。 OP 正在寻找一个可靠的约定来坚持。一个更好的答案是：“不幸的是，C++ 社区对此没有明确的约定”。可悲的是，如果你仔细想想。所有其他流行语言似乎都有一个唯一的文件扩展名。我会坚持一个重要的项目使用什么，比如 gcc。 They use .cc.

标签： c++ filenames

【解决方案1】：

归根结底，这并不重要，因为 C++ 编译器可以处理任何一种格式的文件。如果这是您团队中的一个真正问题，请掷硬币并继续进行实际工作。

【讨论】：

嗯，这是一个有效的观点，但它没有回答用户的问题。
cc 输入速度更快
为什么这是公认的答案？新程序员不会知道这无关紧要，他们应该得到一个直截了当的答案。
答案对于一个好奇而有头脑的程序员来说绝对不够。我想要更多关于this page 的答案，因为它有更详细的解释。
当人们认为编译器通常不是唯一涉及的工具时——几乎总是有“make”或类似的实用程序会关心你使用哪些扩展来匹配构建规则——然后这个答案确实没有解决问题的核心问题。请注意，系统和工具链（包括您最喜欢的制作规则等）会有所不同，这将对决策产生影响。例如，QNX 6 系列开发平台中的一些默认递归多目标构建系统不会将 *.cpp 文件作为 C++ 语言源；它想要.cc

【解决方案2】：

GNU GCC 将以下所有文件识别为 C++ 文件，并且无论您是通过 gcc 还是 g++ 调用它，都将使用 C++ 编译：.C、.cc、.cpp、.CPP、.c++、 .cp，或.cxx。

注意.C - GCC 中的大小写很重要，.c 是 C 文件，而 .C 是 C++ 文件（如果您让编译器决定它正在编译什么）。

GCC 还支持其他后缀来表示特殊处理，例如.ii 文件将被编译为 C++，但不进行预处理（用于单独预处理的代码）。所有识别的后缀在gcc.gnu.org有详细说明

【讨论】：

"大小写在 GCC 中很重要" - Windows 怎么样（因为它不区分大小写）？
@Devesh：Windows 也是。但是操作系统会阻止您将两个文件放在仅按大小写区分的文件夹中。
@DeveshKhandelwal 但它是保留大小写的
@Clifford 从理论上讲，所有版本的 NT 都允许您在一个仅按大小写区分的文件夹中拥有两个（或更多）文件，前提是您通过 FILE_FLAG_POSIX_SEMANTICS 或类似的适当的地方；这就是原始 POSIX 子系统、Interix/SFU/SUA 甚至 WSL 1 的工作方式。 XP 和更高版本要求您 jump through some hoops 启用此功能，但是，如果您这样做，许多应用程序将中断（包括 AV 扫描仪，因此是箍）。
@AlexShpilkin 有趣，在这种情况下并不特别相关。如果你这样做了并且有这样的文件，那么如果没有这个配置，你的项目就无法在 PC 上签出和构建。依赖于文件系统配置的构建是个坏主意。

【解决方案3】：

关于使用 makefile 和其他工具的好建议，在决定使用哪个扩展时考虑非编译器工具是帮助找到适合您的答案的好方法。

我只是想添加以下内容来帮助我找到一些 .cc 与 .cpp 信息。以下是按不同环境细分的扩展（来自“C++ Primer Plus”一书）：

Unix 使用：.C、.cc、.cxx、.c

GNU C++ 使用：.C、.cc、.cxx、.cpp、.c++

Clang 使用：.C、.cc、.cxx、.cpp、.c++ 以及 .cppm 用于模块接口

数字火星使用：.cpp、.cxx

Borland C++ 使用：.cpp

Watcom 使用：.cpp

Microsoft Visual C++ 使用：.cpp、.cxx、.cc 以及 .ixx 用于模块接口

Metrowerks CodeWarrior 使用：.cpp、.cp、.cc、.cxx、.c++

不同的环境支持不同的扩展。我也想回答这个问题并找到了这篇文章。根据这篇文章，我想我可能会选择.hpp 和.cpp，以便于跨平台/跨工具识别。

【讨论】：

在真正尝试解决所提出的问题方面，这个答案比其他答案最接近，这是关于有人在寻找一个可靠的约定来坚持。其他语言有，但就文件扩展名而言，C++ 似乎缺乏它。
Unix在什么意义上不使用.cpp？
vc++6.0 不支持 .cc 文件。
@KeithThompson cehck 用户 user181548 的回答
@SpyrosMourelatos 是的，但在类 Unix 系统上的 C++ 代码仍然非常普遍地使用 .cpp 来处理 C++ 源文件。（引用的答案指出“cpp”是 C 预处理器的缩写。）

【解决方案4】：

.cpp 据我所知是推荐的 C++ 扩展。有些人甚至建议将.hpp 用于 C++ 标头，只是为了与 C 区分开来。

虽然编译器不在乎你做什么，但这是个人喜好。

【讨论】：

我决定从使用 .h 切换到使用 .hpp 作为 c++ 头文件；主要是因为编辑器等其他工具也需要知道 - 此外，当使用 gcc 的预编译头文件时，它默认使用 C 处理 .h 文件和 C++ 处理 .hpp 文件，除非在预编译时使用“-x c++-header”选项.h 文件。
@jd。同意。如果 h/c 文件转换为 hpp/cpp 文件，它会使自动化工具变得容易一些。
g++ 不将 .hpp 识别为 C++ 头文件（用于头文件预编译），但 .hh 可以。因此，我最终使用 .cc/.hh 而不是 .cpp/.hpp，因为实际上并没有任何真正的区别。
@Tronic：由于 4.3 gcc 识别 .hpp，比较 gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Overall-Options.html 和 gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Overall-Options.html
@CharlesAddis - 是的，我必须将同一目录中具有“abcd.H”（c++ 接口）和“abcd.h”（C 接口）的大量代码转换为“abcd” .hpp”和“abcd.h”，因为只是执行“svn co”或解压缩到 Windows 机器或 Mac OS X 机器（使用默认文件系统）会因“重复文件名”而失败

【解决方案5】：

我个人使用.cc 扩展实现文件，.hh 用于标头，.inl 用于内联/模板。

如前所述，主要是口味问题。

据我所见，.cc 似乎更“面向开源项目”，正如一些优秀的开源软件编码风格所建议的那样，而 .cpp 似乎更窗口化。

--- 编辑

如前所述，这是“据我所见”，它可能是错误的。只是我做过的所有Windows项目都使用.cpp，而且很多开源项目（主要是unix-likes）都使用.cc。

使用.cc 的编码样式示例：

【讨论】：

你有这方面的参考吗？我从未见过 OSS .cc 与 Windows .cpp
Visual Studio 为 C++ 创建 .cpp 文件。我不知道它背后的历史。
LLVM 编码标准似乎提倡使用 .cpp/.h 并将 -*- C++ -*- 标签放在标题 llvm.org/docs/CodingStandards.html 中； Mozilla 编码风格建议 .cpp/.h developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/… ； KDE 似乎也在使用 .cpp/.h quickgit.kde.org
上面显示的“Google 编码风格”链接现在已失效。试试这个谷歌风格指南：google.github.io/styleguide/cppguide.html。 @sastinin 评论中的 KDE 编码风格同上。对于 KDE 编码风格指南，请尝试使用“KDE 编码风格”进行 Internet 搜索。

【解决方案6】：

使用的其他文件扩展名包括.cxx 和.C（大写C）。我相信 Bjarne Stroustrup 最初使用的是 .C。 .cpp 是 C 预处理器的名称，因此很遗憾它也用于 C++。

【讨论】：

【解决方案7】：

另一个选项是.cxx，其中x 应该是旋转45° 的正数。

Windows、Mac 和 Linux 都支持 .c++，所以我们应该使用它。

【讨论】：

"x 应该是一个加号旋转" lmao, c++ dweebs 会做任何事情，除了字面上使用 .c++ , .h++

【解决方案8】：

几个人说.cc 不代表什么？它可能。 C++ 最初是“C with Classes”。

.cc 和 .cpp 也是大多数 Unix 系统（分别是 c 编译器和 c 预处理器）上的命令名称。

我只使用.cpp，但我是在 Windows 上开始的。 .cc 更像是一个 Unix 约定，尽管我在那里看到的越来越少。 GNU make 有.cpp 的规则，所以这可能是首选，默认情况下它可以在 Windows 和其他所有东西上工作。另一方面，现代 C++ 根本不使用头文件扩展名，我真的不喜欢这样。我所有的项目都使用.h作为头文件，并且通过extern "C"和测试__cplusplus尽可能地支持C和C++。

【讨论】：

那不应该是.cwc吗？ :)
在许多编译器支持命名空间之前，它们还使用 .h 扩展名作为标准头文件。通常，编译器提供已弃用的 .h 版本，将库放入全局命名空间。这允许支持遗留代码。我曾经在某处读到它们没有 .h 扩展名的原因是标准允许它们不是文件，而是本质上是“内置的”。然而，这可能是杜撰的。

【解决方案9】：

只需遵循项目/团队使用的约定即可。

【讨论】：

【解决方案10】：

在我从事的任何项目中，我个人从未见过.cc，但从技术上讲，编译器不会在意。

谁会关心为您的源代码工作的开发人员，所以我的经验法则是选择您的团队喜欢的内容。如果您的“团队”是开源社区，请选择一些非常常见的东西，其中.cpp 似乎是最受欢迎的。

【讨论】：

github.com/google/googletest 等几个知名项目正在使用.cc 作为 C++ 实现文件的文件扩展名

【解决方案11】：

.cc 扩展名是在 makefile 中使用隐式规则所必需的。浏览这些链接以更好地了解 makefile，但主要看第二个，因为它清楚地说明了 .cc 扩展名的有用性：

ftp://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_2.html

https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_10.html

我现在才知道。

【讨论】：

同样，它们只是 .cpp 文件。不用担心！ :-)
它说“我们鼓励您对 C++ 源文件使用后缀 '.cc' 而不是 '.C'。”我怀疑这只是措辞不佳。在具有不区分大小写的文件系统的系统上使用 .C 可能会出现问题。例如，就make 而言，我认为使用.cc 而不是.cpp 并没有什么特别的优势。对于 C++ 源文件，Makefile 与 .cpp 一起工作得很好。

【解决方案12】：

与大多数样式约定一样，只有两件事很重要：

尽可能保持一致。
不要设计任何依赖于所使用的特定选择的东西。

这些看似矛盾，但它们各有其价值。

【讨论】：

【解决方案13】：

.C 和 .cc 似乎是我见过的（少数）面向 Unix 的 C++ 程序的标准。我自己一直使用.cpp，因为我只在 Windows 上工作，而且这一直是那里的标准。

我个人推荐.cpp，因为...它代表“C Plus Plus”。文件扩展名是首字母缩略词当然非常重要，但如果这个理由证明不足以令人信服，其他重要的事情是不使用 shift 键（排除.C 和.c++）和尽可能避免正则表达式元字符（这排除了.c++——不幸的是，你当然不能真正避免.。）。

这并不排除.cc，所以即使它并不代表任何东西（或者确实如此？）它对于面向 Linux 的代码来说可能是一个不错的选择。

【讨论】：

但是“cpp”也可以代表“C预处理器”。事实上，您系统上的程序“cpp”很可能是 C 预处理器...

【解决方案14】：

我分别使用 .C 和 .h 作为源代码和标头。这种选择的一个好处是，在命令行上，它易于使用*.[Ch] 来选择所有代码文件。在不区分大小写的文件系统上使用.C 可能是个问题，但如果您在同一目录中有foo.c 和foo.C，那么无论如何您都应该得到：)

【讨论】：

【解决方案15】：

您将使用哪些扩展程序并不重要。选择你更喜欢的，只要与命名保持一致即可。我知道这个命名约定的唯一例外是我不能让WinDDK（或者现在是WDK？）来编译.cc文件。不过在 Linux 上这几乎不是问题。

【讨论】：

【解决方案16】：

我正在开始一个新的 C++ 项目并开始寻找最新的 C++ 风格。关于文件命名，我在这里结束了，我想我会分享我是如何提出我的选择的。如下：

Stroustrup 将其视为a business consideration than a technical one。

按照他的建议，让我们检查一下工具链的期望。

对于 UNIX/Linux，您可以将以下默认 GNU make 规则解释为支持 .cc 文件名后缀，因为 .cpp 和 .C 规则只是别名：

$ make -p | egrep COMPILE[^=]+=
COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
COMPILE.cpp = $(COMPILE.cc)
COMPILE.C = $(COMPILE.cc)

（注意：没有默认的 COMPILE.cxx 别名）

因此，如果您的目标是 UNIX/Linux，.cc 和 .cpp 都是很好的选择。

当面向 Windows 时，您正在寻找 .C 的问题，因为它的文件系统不区分大小写。您可能需要注意Visual Studio favors the .cpp suffix

当面向 macOS 时，请注意 Xcode 更喜欢 .cpp/.hpp（刚刚在 Xcode 10.1 上检查过）。您可以随时更改标题模板以使用 .h。

对于它的价值，您还可以根据自己喜欢的代码库做出决定。例如，Google uses .cc 和 LLVM libc++ 使用 .cpp。

头文件呢？它们是在 C 或 C++ 文件的上下文中编译的，因此不需要编译器或构建系统来区分 .h 和 .hpp。然而，您的编辑器/IDE 的语法高亮和自动缩进可能是一个问题，但是通过将所有 .h 文件关联到 C++ 模式可以解决此问题。例如，我在 Linux 上的 emacs 配置以 C++ 模式加载所有 .h 文件，并且可以很好地编辑 C 头文件。除此之外，在混合 C 和 C++ 时，您可以关注此advice。

我个人的结论：.cpp/.h是阻力最小的路径。

【讨论】：

需要注意的是，Mac的默认文件系统也是不区分大小写的。

【解决方案17】：

正如其他人在我之前写的那样，最后是您的项目/团队/公司正在使用的东西。

就个人而言，我没有使用cc 扩展，我试图减少扩展的数量而不是增加它们，除非有明确的价值（在我看来）。

对于它的价值，这就是 我正在使用的：

c - 仅纯 C 代码，没有类或带有方法的结构。

cpp - C++ 代码

hpp - 仅标头代码。实现在标题中（如模板类）

h - C/C++ 的头文件。我同意可以进行另一种区分，但正如我所写的，为了简单起见，我正在尝试减少扩展的数量。至少从我参与的 C++ 项目来看，纯 C 的 h 文件比较少见，因此我不想添加另一个扩展。

【讨论】：