2

起初看到即将推出的 C++0x 标准时，我很高兴，并不是我悲观，而是现在想到它，我感到有点不那么希望了。

主要是因为三个原因：

  1. 很多提升膨胀（这一定会导致编译时间绝望？），
  2. 语法似乎很长（不像我最初希望的那样 Pythonic），并且
  3. 我对便携性和其他平台（iPhone、Xbox、Wii、Mac）非常感兴趣，难道“标准”需要很长时间才能变得足够便携吗？

我想＃3风险较小，从过去十年的模板中吸取了教训；然而魔鬼在细节中。

编辑 2（尽量减少奇思妙想）：您认为公司在标准生效的第一年过渡到 C++0x 是安全的，还是会带来很大的风险？

4

8 回答 8

14
  1. 您只需为使用的内容付费。如果您不需要复杂的模板功能，请不要#include 它定义的标题，您不必处理它。
  2. Lambda 函数应该能很好地减少 STL 算法的冗长；和auto变量将有助于代码std::map<foo, std::shared_ptr<std::vector<bar> > >::const_iterator...
  3. 是的，这需要一段时间。许多新功能确实在增强，如果您想要可移植性，那么您应该在标准实施后至少使用几年。幸运的是，只有两个编译器涵盖了您提到的那些平台：g++ 和 Microsoft 的 C++ 编译器。一旦他们得到支持，嵌入式工具链用新版本重建只是时间问题。不幸的是，可能很多时间...
于 2009-08-12T15:24:52.867 回答
13

编辑：我（和其他像我一样的人）是否必须密切关注构建时间、不可读的代码和缺乏可移植性，并进行大规模原型设计以确保继续使用新标准是安全的？

是的。但是你也必须用当前的标准来做所有这些事情。我没有看到 C++0x 变得更糟。

C++ 构建时间总是很糟糕。不过，C++0x 没有理由比现在慢。与往常一样，您只包含您需要的标题。据我所知，每个标题都没有明显变大。

当然，概念是这里最大的未知数之一，人们担心它们会显着减慢编译时间。这是他们被裁掉的众多原因之一。

如果您不小心，C++ 很容易变得不可读。同样，那里没有什么新鲜事。再一次，C++0x 提供了很多工具来帮助最小化这个问题。Lambda 不像 Python 或 SML 那样简洁，但它们比我们今天必须定义的函子更具可读性。

至于可移植性，C++ 已经是一个雷区。不保证整数类型大小，也不保证字符串编码。在这两种情况下，C++0x 都提供了解决此问题的工具（使用 Unicode 特定的字符类型和保证固定大小的整数）

即将出台的标准明确了目前阻碍可移植性的一些问题。

所以总的来说，是的，你提到的问题是真实的。它们今天存在，它们将存在于 C++0x 中。但据我所知，C++0x 减轻了这些问题的影响。它不会让他们变得更糟。

没错，合规标准需要一段时间才能在所有平台上可用。但我认为这将是一个比 C++98 更快的过程。

所有主要的编译器供应商似乎都非常热衷于 C++0x 支持，而上次并非如此。（可能是因为当时主要是调整和修复他们已经实现的预标准功能，所以更容易声称您的预标准编译器“几乎与 C++98 兼容”。

我认为总的来说，C++ 社区比十年前更加关注标准和前瞻性。如果你想出售你的编译器，你将不得不认真对待 C++0x。

但是从标准发布到完全（或大部分）兼容的编译器可用，肯定会有几年的时间。

于 2009-08-12T17:03:14.557 回答
10

像大多数 C++ 一样，您只需为所需的内容付费。因此，如果您不想要有用的跟踪指针、线程库等的“增强膨胀”，那么您不需要为编译付费。

我非常确定设计将解决可移植性问题，特别是因为很多都是基于来自 boost 等项目的现有可移植代码。GCC 和 Microsoft VC 都已经实现了 C++ 0x 的大部分内容，正如您从它们各自当前的原型版本中看到的那样。

于 2009-08-12T15:22:00.503 回答
6
  1. C++ 总是会有无望的编译时间，它的整个理念是做一次事情（即在编译时做），所以你不必在运行时重复它并降低性能。正如其他人所说，如果您不需要它，请不要包含库！
  2. C++ 永远不会非常 Pythonic，因为它的目标是向后兼容。冗长来自作为一种古老的语言，随着语言的发展增加了许多东西。正如其他人所说，lambdas 和 auto 变量也将大大减少冗长
  3. 这是对语言进行任何重大更改的问题，但我认为人们普遍认为这些更改将使该语言更易于使用，因此应该迅速采用。
于 2009-08-12T15:36:08.790 回答
3

我实际上认为#3 是短期内最大的风险。AFAIK，该标准在几个领域（lambdas）引入了新语法并改变了以前单词的含义（例如 auto）。只有当您部署的每个平台的编译器都支持这些功能时，使用这些功能的代码才能移植。

当然，这会在某个时间点发生。但是向编译器添加新功能可不是一件小事，而且需要相当长的时间。我担心主要编译器支持这些功能需要很长时间，从而抑制程序员成为早期采用者和可移植性的能力。

于 2009-08-12T15:22:52.187 回答
2

我发现 C++0x 在很多情况下让代码更清晰。

由于可变参数模板，在处理大量模板化代码时，构建时间可以大大缩短。boost:: 使用一个非常丑陋的模板重载方案来在 C++98 中实现“可变参数模板”。这会导致编译时间过长。关联

基于范围的 for 循环对于可读性也很好。

考虑 C++98-ish：

for (std::vector<int>::const_iterator itr = vec.begin(); itr != vec.end(); ++itr)
   foo(*itr);

现在可以写成（在 G++ 4.6 中实现）为：

for (auto elem : vec)
   foo(elem);

auto关键字也减少了句法噪音。

Lambdas are great for use with STL algorithms as well, and makes it more readable when you don't have to separately create C style callback functions or even a whole class.

于 2010-12-24T14:56:54.377 回答
1

标准事物的优点之一是编译器可以走捷径。例如，如果您可以简单地移交给X ，那么实现is_X<U>所需的 boost 模板马戏团就会消失。这可以轻松节省 2 个数量级，有时是 3 个数量级。__compiler__is_<U>

于 2009-08-13T11:41:40.493 回答
0

这里有什么问题？当然，在深奥平台上的编译器实现这些特性还需要几年的时间。不要指望能够使用新功能，直到 3 年，也许 5 年后。正如我们用荷兰语所说的那样，“然后活着，然后忧虑”。

于 2009-08-12T15:22:15.243 回答