这个问题的答案是特定于平台的; 例如,Linux 上发生的情况与 Solaris 上发生的情况不同。
最简单的部分(因为它不是特定于平台的)是将‘ gcc’和‘ g + +’分开:
GCC 是来自 gCC (GCC)的 GNU c 编译器。
G + + 是来自 GCC 的 GNU C + + 编译器。
最困难的部分是“ CC”(和“ CC”)的含义,因为它是特定于平台的。
在 Solaris 上,CC 通常是 Sun C + + 编译器的名称。
在 Solaris 上,cc 通常是 Sun C 编译器的名称。
在 Linux 上,如果存在 CC,那么它可能是到 g + + 的链接。
在 Linux 上,cc 是到 gcc 的链接。
然而,即使在 Solaris 上,cc 也可能是来自 /usr/ucb的旧的基于 BSD 的 C 编译器。在实践中,这通常不会被安装,只有一个存根会失败,对那些尝试编译和安装自配置软件的人造成严重破坏。
在 HP-UX 上,默认的“ cc”仍然是只安装了 K & R 的 C 编译器,以允许在必要时重新链接内核,并且不能用于现代软件工作,因为它不支持标准 C。您必须使用替代的编译器名称(‘ acc’IIRC)。类似地,在 AIX,系统 c 编译器的名称是“ xlc”或“ xlc32”。
通常,默认的系统编译器被称为“ cc”,当自配置软件不知道还能使用什么时,就使用这个名称。
POSIX 试图通过要求程序 c89(最初)和后来的 c99存在来规范它的方式; 这些是与 ISO/IEC 9899:1989和9899:1999 C 标准兼容的编译器。POSIX 能否成功值得怀疑。
这个问题询问在特性和库方面的差异。和以前一样,答案部分是特定于平台的,部分是通用的。
C 编译器和 C + + 编译器之间的巨大差异。C + + 编译器将接受 C + + 程序,不会编译任意的 C 程序。(尽管可以在一个子集中编写 C 语言,这个子集也可以被 C + + 理解,但是许多 C 程序并不是有效的 C + + 程序)。类似地,C 编译器将接受 C 程序并拒绝大多数 C + + 程序(因为大多数 C + + 程序使用 C 中不可用的构造)。
可供使用的库集取决于语言。C + + 程序通常可以在给定的平台上使用 C 库; C 程序通常不能使用 C + + 库。因此,C + + 有更多的库可用。
请注意,如果你在 Solaris 上,CC 生成的对象代码与 g + + 生成的对象代码不兼容——它们是两个独立的编译器,对于异常处理和名称错位(名称错位是故意不同的,以确保不兼容的对象文件不会链接在一起!).这意味着,如果要使用用 CC 编译的库,则必须用 CC 编译整个程序。这也意味着,如果您想使用一个使用 CC 编译的库和另一个使用 g + + 编译的库,那么您就不走运了。至少需要重新编译其中一个库。