1

类型特征很酷，自从几年前它们起源于 boost 以来，我就一直在使用它们。但是，当您查看它们的实现时（查看“如何is_base_of工作？” StackOverflow 线程）。

为什么编译器在这里没有帮助？例如，如果你想检查某个类是否是另一个类的基础，编译器已经知道了，为什么不能告诉我们呢？这将使概念之类的东西更容易实现和使用。你可以在那里使用语言结构。

我不确定，但我猜它会提高整体性能。这就像向编译器寻求帮助，而不是 C++ 语言。

我怀疑主要原因听起来像是“我们需要保持向后兼容性”，我同意，但是为什么编译器不会更积极地生成通用模板代码呢？

4

3 回答 3

5

实际上......有些人这样做。

问题是，如果可以在纯 C++ 代码中实现某些东西，那么除了简化代码之外，没有理由将它们硬连接到编译器中。那么这是一个权衡的问题，代码简化带来的价值是否值得硬接线？

这取决于几点：

  • 正确性（有时软件可能只能部分模拟该特征）
  • 代码复杂~~维护负担
  • 表现
  • ...

一旦对所有这些点进行了加权，您就可以确定将内容放入库还是编译器是否更有利；更有可能的情况是您最终会采用混合策略：编译器中的几个内在函数用作构建块，以在库中提供所需的接口。

请注意，编译器的维护负担要大得多：任何充分熟悉该语言的 C++ 开发人员都可以深入研究库实现，而编译器代码是一个黑盒。因此，调试和修补库比编译器容易得多，所以除非你有充分的理由，否则不要将东西放入编译器。

于 2013-01-28T10:09:49.200 回答
0

在这里很难给出客观的答案，但我怀疑以下几点。

  1. 使用语言怪癖来找出这些东西的代码通常已经编写好了（Boost 等）。
  2. 如果可以通过语言怪癖来完成，则无需更改编译器即可实现这一点（这可以节省大量编写、编译、调试和测试的时间）。

这基本上是一种“不修复没有损坏的东西”的心态。

于 2013-01-28T09:24:46.067 回答
0

类型特征的编译器帮助一直是设计目标。TR1 正式引入了类型特征，并包括一个描述在某些情况下可接受的不正确结果的部分，以便能够直接用 C++ 编写类型特征。当这些类型特征被添加到 C++11（一些名称更改不影响其实现）时，允许不正确的结果被删除，实际上需要编译器帮助来实现其中的一些。即使对于那些可以直接用 C++ 实现的程序，编译器编写者也更喜欢内在函数而不是复杂的模板，这样您就不必在计算机下放置一个滴盘来接渣，因为过度工作的编译器会导致计算机崩溃。

于 2013-01-28T13:42:28.460 回答