我正在查看gcc的源代码(出于好奇心),我注意到了一个我以前从未见过的数据结构。
在解析器中的80和129(以及许多其他地方),他们似乎在使用向量。
80: vec<tree> incomplete_record_decls;
129: ridpointers = ggc_cleared_vec_alloc<tree> ((int) RID_MAX);
我从未在C中遇到过这种数据类型,也没有遇到过:< >
。它们原产于C吗?
有谁知道它们是什么以及如何使用它们?
自GCC 4.8以来,GCC已从C转向C ++。这项工作实际上已经开始了很久,与creation of gcc-in-cxx
branch。开发人员首先尝试使用C ++编译器编译源代码,因此没有任何名称更改。我猜他们以后在merging the two branches和官方只有一个C ++分支时没有重命名文件
您可以阅读GCC's move to C++以获取更多历史信息
尽管有.c文件名,但这段代码无效C;它是C ++,使用该语言的template功能。如果检查gcc构建过程,您会发现该文件实际上是使用C ++编译器编译的。
https://gcc.gnu.org/codingconventions.html
目录gcc,libcpp和fixincludes可能使用C ++ 03。如果主机C ++编译器支持long long类型,它们也可以使用long long类型。这些目录应该使用C ++ 03的合理可移植部分,这样就可以用GCC本身以外的C ++编译器构建GCC。如果测试显示合理的最新版本的非GCC C ++编译器无法编译GCC,则应相应地调整GCC代码。 (避免异常的语言结构有很大帮助。)此外,这些目录也应与C ++ 11兼容。
请记住,虽然编译器通常会默认从文件名中推断出源文件的语言,但始终可以覆盖此默认值。完全有可能在.c文件中使用C ++代码,或者在.bas文件中使用C代码;你可能不得不告诉编译器一些其他方式正在使用的语言。
我希望gcc选择这个文件命名约定,因为这段代码最初用C编写,后来转换为C ++,他们发现更改所有文件名太麻烦了。更新所有makefile等意味着很多工作。只是改变使用哪个编译器并向所有开发人员解释约定可能不那么痛苦。当然,一般来说,以标准方式命名文件是更好的编程习惯,但显然gcc开发人员认为这不是这种情况下的最佳行动方案。