C++ 标准特性和二进制大小

Question

我最近在一次工作面试中被告知他们的项目致力于为他们的应用程序构建最小大小的二进制文件(嵌入式运行)所以我将无法使用诸如模板或智能指针之类的东西，因为它们会增加二进制文件的大小，他们通常似乎暗示使用 std 中的东西通常是不行的(并非所有情况)。

采访结束后，我尝试在网上研究编码以及标准库中的哪些功能导致二进制文件过大，但我基本上找不到任何相关信息。有没有一种方法可以量化使用某些功能及其对大小的影响(例如，无需在代码库中编写 100 个智能指针与 self 管理相比)。

Answer 1

这个问题可能比它可能得到的更值得关注，尤其是对于那些试图在嵌入式系统领域谋求职业的人来说。到目前为止，讨论已经按照我所期望的方式进行，特别是很多关于使用 C++ 构建的项目究竟如何以及何时可能比用普通 C 或受限制的 C++ 子集编写的项目更加臃肿的细微差别的讨论。

这也是为什么您无法通过老式的谷歌搜索找到明确答案的原因。因为如果您只是问“C++ 比 X 更臃肿吗？”这个问题，答案总是“视情况而定”。

所以让我从一个稍微不同的角度来探讨这个问题。我曾在执行此类限制的公司工作和面试过，我什至自己也自愿执行过这些限制。这真的归结为这一点。当你经营一个工程组织时，有不止一个人计划继续招聘，假设你团队中的每个人都会完全理解使用语言的每一个特性的含义是非常不切实际的。编码标准和语言限制是防止人们在不知道自己在做“坏事”的情况下做“坏事”的廉价方法。

然后，您如何定义“坏事”也是特定于上下文的。在桌面平台上，使用大量代码空间并不是真正“糟糕”到需要严格执行的事情。在微型嵌入式系统上，它可能是。

C++ 的设计使工程师可以非常轻松地生成大量代码，而无需显式键入。我认为这句话是不言自明的，这是元编程的全部要点，我怀疑有人会质疑它，事实上，这是该语言的优势之一。

那么回到组织挑战上来，如果您的主要优化变量是代码空间，您可能不想让人们使用使生成不明显代码变得微不足道的功能。有些人会负责任地使用该功能，有些人不会，但您必须围绕最小公分母进行标准化。 C 编译器非常简单。是的，您可以用它编写臃肿的代码，但如果您这样做，从外观上看可能会非常明显。