Everett：Visual C++ 开发人员的下一个重大事件
5.00/5 (1投票)
Microsoft 的 Visual C++ .NET 产品经理谈论 Visual Studio .NET 下一版本将发生的变化
Microsoft Visual C++ .NET 产品经理谈论 Everett。
Nick Hodapp 是 Microsoft Visual C++ .NET 的产品经理，也是我们每月《Semicolon》专栏的作者。他的主要工作之一是密切关注 Visual C++ 社区的动向，并将这些信息反馈给 Microsoft 的产品团队。“这是一项艰巨的任务——我们是一个充满活力（有时也很难缠）的群体。”
早在 Visual Studio .NET 2002 发布时，最耀眼的明星是 C#，紧随其后的是 VB.NET。C++ 开发人员在很多情况下被冷落了。是的，我们有 Managed Extensions 和 ATL Server，但没有 Windows Forms 设计器，也没有机会在 ASP.NET 中使用 VC++.NET（除非你喜欢 IIS 崩溃）。我们获得了一些不错的优化和内置安全检查，但对许多人来说，Visual C++ 似乎被忽视了，并将被降级为系统级编程。总之，Visual C++ 似乎会沦为过时语言的退休之家，与 FORTRAN 一起讲述昔日的辉煌。
Microsoft 即将发布 Everett（发布日期尚未公布；他们说“明年年初”）。我们对此已有近一年的预告，但 Nothing concrete。然而，今天，Bill Gates 几乎揭开了 Everett 的面纱，我与 Nick 进行了交谈，了解了 Everett 为 Visual C++ 开发人员带来了什么。
首先：Everett 是什么？
Everett 是 Visual Studio .NET 下一个版本的代号——官方名称仍未公开。Everett 对于 Visual C++ 开发人员来说是一个重大版本，而对于 C# 和 Visual Basic .NET 开发人员来说，它基本上是一个增量升级。
那么 C++ 开发人员能获得什么呢？
Everett 中最大的改进是：符合 ISO 标准，支持 Windows Forms 设计器；新的编译器优化和代码安全功能增强。
此外，Managed Extensions、MFC/ATL 库以及 Debugger 和 IDE 中还有一些小的 Bug 修复。
Microsoft 人员已经暗示了这个版本中的兼容性工作一年多了。我们到底得到了什么？
在 Everett 中，我们实现了对 C++ ISO 标准 98% 的兼容。没有编译器能达到 100%，而且兼容性的衡量非常困难，因为没有单一公认的测试套件。我们使用了 3 个——Perennial、Plumb Hall 和 Dinkumware——并且每个都通过了 98% 以上的测试。但我们最喜欢的基准是，我们可以在无需特殊规避措施的情况下编译流行的 Boost、Blitz 和 Loki 库。我们认为 C++ 的大量创新都发生在这些社区编写的库中，Visual C++ 能够编译它们非常重要。Visual C++ 开发人员现在可以使用与 C++ 社区其他成员相同的库，从而成为更广泛 C++ 社区的一部分。此外，我们终于能够使用标准中定义的一些高级模板功能来编写代码了。
我们还没有达到 100%，但预计我们会朝着完全兼容的方向前进。特别是 ISO 功能“Export”和“Exception Specifications”非常棘手，并且关于它们的用途存在很多争论。它们仍然在考虑中。
Nick 发来了一份编译器中新增特定功能的列表。它们包括：
- 2.2 Unicode 标识符
- 3.4.2 完全的 Koenig 查找
- 8.5.1 空聚合初始化
- 9.8 局部成员函数的符号查找
- 11.4 类模板中的友元（也见 14.5.3）
- 13.3.1.1.2 指向函数指针的隐式调用转换
- 13.3.3.2 派生到基类转换的排序
- 14.1 非类型模板参数（也见 14.3.2）
- 14.5.2 用户定义的转换模板
- 14.5.4 类模板的偏特化
- 14.5.5.2 函数模板的偏序
- 14.7.1 类模板中的嵌套类
- 14.7.3 成员模板的显式特化
- 15.5.2 unexpected() 函数
VC7 已经有一些不错的性能改进——考虑到它是编译器的第 13 个版本，他们仍然实现了大约 10% 的提升，这令人印象深刻。那么 7.1 呢？
C++ 因其性能而被选择，所以我们总是希望确保我们的编译器是最好的。为此，我们为针对 Pentium IV 和 Athlon 芯片的应用程序引入了新的开关，这些开关可能提供额外的 5-10% 的性能提升，具体取决于代码类型。对于重浮点运算，您可能会看到高达 15% 的性能提升。
两个新开关 /arch:SSE 和 /arch:SSE2 针对现代处理器上的流式 SIMD 指令。在使用这些指令进行浮点代码处理时，我们看到了大约 2-3% 的性能提升。
此外，我们还增强了现有优化，例如“全程序优化”。
您提到了 C++ 应用程序的代码安全性得到了改进。以何种形式？
C++ 精简高效，但它在代码安全性方面也可能受到诟病。Microsoft 非常关注保护我们自己的产品以及客户的产品，因此我们在 VS.NET 中引入了 /GS 标志，作为帮助缓解缓冲区溢出漏洞的工具。在 Everett 中，我们扩展了编译器“理解”的攻击类型。我们还增强了该功能，使其能够与 Windows .NET Server 协同工作。
使用 /GS 编译并在 Windows .NET Server 上运行的应用程序，其异常表将在加载时由操作系统加载。如果在程序运行过程中发生异常，操作系统将检查程序尝试跳转以处理异常的指令位置。如果该地址不在操作系统最初加载的表中，则假定正在进行攻击，程序将立即终止。这会将一个潜在的毁灭性问题变成一个虽然令人不快但安全的麻烦。
但是，使用这些安全检查的应用程序会受到性能影响吗？
通常“不会”。新编译器生成的代码比当前版本或 VC6 更加优化，因此使用 Everett 编译带来的速度提升 outweighs 使用 /GS 编译的任何性能损失。我们看到的 worst-case 场景是 2% 的性能下降，但总的来说我们几乎注意不到任何影响。在 Everett 中，每一次成功的安全检查只有九条指令，并且所有这些指令都易于缓存，不会导致分支预测错误。因此，总的来说，使用优化和 /GS 在 Everett 中编译代码将比以前版本生成的代码更快。
VS.NET 中最显著的缺失功能之一是 VC++ 的 Windows Forms 设计器支持。这已经被提及了很多次，但它是否已经交付了？
是的。Everett 为 VC++.NET 提供了 Windows Forms 的 RAD 支持。
那么 ASP.NET 支持呢？
当前版本中存在一个已知问题，即使用 Managed C++ 构建的组件在从 ASP.NET 页面调用时有时会导致 IIS 崩溃。这是一个已记录在案的 App-Domain 问题，在 Everett 中已修复。现在可以在 ASP.NET 应用程序中自由使用 Managed C++ 组件。
C++ 没有 Web Forms 支持。我们对此考虑了很多，但说实话，似乎没有需求包含它。
IDE 中与 VC++ 相关的 Bug 是否已被修复？
都有哪些 Bug 呢？说实话，我们为 C++ 开发人员在 IDE 方面做了大量工作来改进。它不是“全新”的，但我们确实修复了项目生成系统、任务列表和动态帮助方面的许多问题。哦，还有一些在 CodeProject 上经常被提及的资源编辑器 Bug。我希望我们已经修复了其中大部分。
那么，Visual Studio .NET 2003 何时发布？
我们仍然目标是在今年 RTM。预计将在明年初上市。发布日期取决于多种因素，并非所有因素都与 Visual C++ 相关。请耐心等待！
Visual Studio .NET 'Everett' 升级路径
随着 Visual Studio .NET 新版本的即将发布，许多开发人员担心他们购买的产品会在几个月内过时，因此不愿购买当前版本的 Visual Studio .NET。Microsoft 已在其路线图上宣布，MSDN 订阅者（Universal、Enterprise 或 Professional）将在发布后立即获得更新，而 Visual Studio .NET 的用户可以以 29 美元的价格进行升级（以支付媒体、邮费和处理费用）。如果您拥有 Visual Studio .NET 并且不想支付 29 美元，Microsoft 将在同一时间提供一个免费的服务包，该服务包仅包含 VS.NET 的 Bug 修复。