3

我一直试图让我们的团队将一个大型 C++ 项目从 VS2008 迁移到 VS2012。我想这样做主要是因为我想开始使用 C++11 并且 IDE 更好。所以我的理由有些自私。

我的团队负责人正在回击，因为他没有看到迁移的商业案例，理由是我们将在 C++11 中获得的大多数性能改进功能我们已经在 BOOST 和其他库中拥有。他还表示，这将需要在我们所有平台上更改运行时，这可能会改变某些行为。这意味着我们需要在我们部署到的所有服务器上重新测试。

我有点理解第一个论点，尽管我相信 C++11 代码会比使用 BOOST 更干净（同样不是一个很好的商业案例）。

关于使用不同运行时的争论我不明白。原生 C++ 应用程序使用哪些运行时？这不是 VC++。他会担心 STL 不会是完全相同的实现吗？

我看不出会有什么问题。有什么我想念的吗？我应该引用其他什么好的迁移论据来帮助我的案例吗？

4

3 回答 3

5
  • 所有第 3 方库都需要使用新编译器构建
  • 代码当前可能在不知不觉中依赖于未定义的行为，新的编译器可能会为 UB 做一些与当前编译器完全不同的事情（并导致问题）

性能不会有太大变化，因为您不会以 C++11 风格进行编码（基本上，很多东西是按值传递的，而以前不会这样）。如果你的代码库有很多...

std::vector<Blah> func(std::vector<Asdf> v); // notice all the pass by value

... C++11 可能是一个很大的性能改进。但是在 C++98/03 中你不会那样做。

您需要降低团队领导的进入门槛。自己进行迁移并对您的产品进行冒烟测试。然后给他看。之后，以下是升级的抽象原因：

  • C++11 风格代码更少，更简单
  • VS2012 增加了 C++11 标准库 - 你可以停止手动滚动 50 个错误缠身的替换
  • 程序员希望使用现代语言和现代工具工作。这将引发公司范围内学习和最佳实践的复苏，这将提高代码质量、员工保留率、员工继续教育等
  • 何时进行这种升级是一个微妙的平衡。如果你经常这样做，你就是在花钱而没有获得任何商业优势。如果您不经常这样做，那么您将处理如此多的遗留技术和遗留代码，以至于维护可能成为一场噩梦。当一个重大的语言变化到来时，你最终会转向，最好早点做（顺便说一句，这不是特别快）——​​否则你只会继续积累以后将被视为遗留代码的东西。为新工具迁移到新的编译器通常是不值得的。进行重要的语言升级通常是值得的。

这是否对你的团队领导有吸引力是我无法理解的。祝你好运

于 2013-10-17T19:59:35.510 回答
2

VS2012 去年就这么过时了，这么好的微软用了一年就换掉了，批评，白瞎，全大写！

但是考虑到您可以在较新的 IDE 中构建 VS2008 项目，这意味着您现在可以升级到 VS2013，并随着时间的推移将项目升级到 VS2013 工具。

虽然您的 TL 是正确的，但升级需要完全重新测试，但如果您在添加功能之间有时间，那么可以进行如此大的测试。

我想说升级的主要方面只是保持最新状态，今天这没什么大不了的，但是再过 5 年，您的旧 VS2008 版本可能会开始阻碍您（据我所知，最近升级了 VS2002 项目到 2010 年），远远落后不是一个好主意，因为你离开的时间越长，你最终必须做的升级工作就越大。这是这样做的真正原因 - 微软在下一个版本中将不支持 2008 构建，并且较旧的 IDE 将无法在 Windows 9 上运行，这种可能性每年都在增加。最好在你有时间的时候解决这个问题。

于 2013-10-17T21:10:09.993 回答
0

我想我对性能改进的期望不高，但是关于测试，我建议对任何类型的编译器或工具链更改进行全面重新测试，无论您是否更改代码。

编辑：我会补充一点，我会在下一个发布周期推动移动到更新的编译器......这会删除测试参数（因为无论如何你都需要测试）。

于 2013-10-17T19:37:07.730 回答