C中的向量和<>是什么?

Lia*_*F-A 6 c compiler-construction gcc vector

我一直在寻找gcc的源代码(出于好奇),并且发现了一个以前从未在C中见过的数据结构。

在解析器的第80129行(以及许多其他位置),它们似乎正在使用向量。

80:  vec<tree> incomplete_record_decls;
129: ridpointers = ggc_cleared_vec_alloc<tree> ((int) RID_MAX);
Run Code Online (Sandbox Code Playgroud)

我从来没有在C中遇到过这种数据类型,也没有这些:< >。它们是C原生的吗?

有谁知道它们是什么以及如何使用它们?

Nat*_*dge 9

尽管文件名是.c,但此代码无效C。它是使用该语言的模板功能的C ++ 。如果检查gcc生成过程,您会发现此文件实际上是使用C ++编译器编译的。

https://gcc.gnu.org/codingconventions.html

目录gcc,libcpp和fixincludes可以使用C ++ 03。如果主机C ++编译器支持,则它们也可以使用long long类型。这些目录应使用C ++ 03的可移植部分,以便可以使用GCC本身以外的C ++编译器来构建GCC。如果测试表明合理的最新版本的非GCC C ++编译器无法编译GCC,则应相应地调整GCC代码。(避免使用不寻常的语言构造会极大地帮助您。)此外,这些目录还应该与C ++ 11兼容。

请记住,尽管默认情况下编译器通常会从文件名中推断出源文件的语言,但始终可以覆盖此默认值。为此,完全可以在.c文件中包含C ++代码,或者在.bas文件中包含C代码。您可能只需要以其他方式告诉编译器正在使用哪种语言。

我希望gcc选择此文件命名约定,因为该代码最初是用C编写的,后来又转换为C ++,并且他们发现更改所有文件名太麻烦了。更新所有的makefile等将需要大量的工作。仅更改使用的编译器并向所有开发人员解释该约定可能就不那么麻烦了。当然,通常最好以标准方式命名文件,这是更好的编程习惯,但显然,海湾合作委员会开发人员认为,在这种情况下,这并不是最佳的做法。

  • @JohnBollinger:是的,很奇怪。我认为这是有历史的:该代码最初是用C编写的,后来由于有用而开始合并C ++的一些位,大概他们认为更改所有文件名会很痛苦。我怀疑支持其他编译器是一个严重的问题。只需通过命令行选项告诉它使用哪种语言即可。 (5认同)
  • 尽管我同意该代码似乎是C ++,但仍奇怪的是,该文件使用的扩展名通常将文件标识为包含C源代码,而不是C ++。文档摘录没有解释这种奇怪之处;实际上,强调支持GCC以外的其他C ++编译器似乎意味着避免此类不合常规。 (3认同)

phu*_*clv 6

自GCC 4.8起,GCC已从C移至C ++

现在,GCC使用C ++作为其实现语言。这意味着要从源代码构建GCC,您将需要一个能够理解C ++ 2003的C ++编译器。有关基本原理和特定更改的更多详细信息,请参阅C ++转换页面。

GCC 4.8版本系列-更改,新功能和修复

实际上,在创建gcc-in-cxx分支之前,这项工作实际上早就开始了。开发人员首先尝试使用C ++编译器来编译源代码,因此没有任何名称更改。我猜他们稍后合并两个分支时便不会再为文件重命名,并且正式只有一个C ++分支

您可以阅读GCC转向C ++的更多历史信息

  • 不,C仍然是C。其中没有类或模板。仅仅是** GCC编译器是用C ++编写的**。编译器和语言是不同的东西 (3认同)