STL：bug的析构函数

我是Visual C++库团队的最新开发人员。我的真名是斯蒂芬T。拉瓦维，但我经常用我非常方便的缩写。今年年初，我在完成outlook2007搜索之后搬到了这里。

你知道吗，有些人是哈利波特小说的粉丝，为了成为第一批体验魔法新冒险的人，他们在午夜时分站在书店外排队？我是用C++的国际标准来做的。下面的评论适用于“原生”C++。我不做托管代码。）这是一个大文档，描述了最大的语言。它的标准库大小适中，但非常强调一般计算，而这远不是它通常认为的解决问题（就抽象而言，而不是图灵完整性而言）。

容器迭代器算法的函数结构有可能由C++实现，并由标准模板库引入，使其同时强大和轻量级。通过以新的方式（在compiletime使用模板，而不是在运行时使用继承）攻击旧问题（我们如何概括容器和算法？），STL将bug（程序员的祸根）推到了compiletime而不是运行时。更早发现错误总是比找到它们更佳，即使你必须解码笨拙的模板错误消息（下一个C++标准应该帮助的东西）。使错误更明显和更快地发现并不是STL所做的唯一伟大的事情，但它无疑是最重要的事情之一。

当然，并非所有的不好都可以在编译时找到。STL对性能的关注相当全面，C++也一样。这意味着标准库实现不需要执行边界检查。STL的结构使得正确编写的程序很难提交边界错误，但并非不可能。此外，某些形式的检查与最大性能本身是不兼容的。STL允许高级容器操作，比如在容器中插入和删除元素的范围，或者从容器中删除所有重复项，等等。程序可以同时将迭代器维护到容器中，当修改容器时，这些迭代器可能会失效。例如，当足够的元素被推回到一个向量中时，向量最终会耗尽容量，必须将其元素重新分配到一个更大的内存块中。用于指向元素的旧位置的迭代器因此无效(指针和引用也是如此。）对无效迭代器执行运行时检查会带来很大的性能开销，因此不需要标准库实现来执行。

迭代器失效并不是一个巨大的、令人讨厌的问题。但是对于程序员来说，能够让他们的编译器执行彻底的正确性检查也是件好事。因此，VisualStudio2005提供了迭代器检查和调试。迭代器检查（由u SECUREu SCL控制）默认情况下在发布和调试模式下都启用，并检测边界错误。迭代器调试（由u HAS u Iterator u debuging控制）默认情况下在调试模式下启用（在发布模式下无法启用），并检测无效错误。使用迭代器检查和调试不需要做任何特殊的工作，只需免费获取即可。

但是，任何东西都有bug，包括bug查找机制。到目前为止，我已经研究了几个这样的错误。其中之一，visualstudio2005sp1中的回归，是在调试模式下编译程序，禁用迭代器调试（这不是默认设置），将迭代器获取到容器中，并在迭代器之前销毁容器而触发的。这引发坠机的原因是漫长而复杂的，弄清楚这段历史很有趣。我们已经修复了奥卡斯的回归。

另一个由不那么晦涩的代码触发的bug涉及到编译时启用了u SECUREu SCL，但u禁用了迭代器调试（默认情况下是在发布模式下，可在调试模式下获得）以及交换两个容器。在交换之后，指向这些容器的迭代器应该仍然有效，但是迭代器检查机制会混淆，从而触发断言。我们正在奥卡斯解决这个问题。

标准库实现中的错误，数十万（可能数百万？）程序员指望它正常工作，这不是什么有趣的事情。好消息是：我们已经意识到这两个错误，还有许多其他的错误，这都要感谢那些通过microsoftconnect报告这些错误的客户。我们的人工测试人员和他们的自动化测试发现了许多bug，但是他们不可避免地会错过全球程序员将要遇到的bug。您，我们的客户，拥有上千万行（可能是上亿行？）的源代码，使用核心语言和标准库的每个黑暗角落。如果您发现了一个bug，并且非常确信它不在您的代码中，请创建一个好的测试用例并将其提交给microsoftconnect。它会在我们的过程中蜿蜒前行，最终落到像我这样的真人的办公桌上。我们解决后你甚至会得到我们的回复。每次看到它的实际应用，我仍然印象深刻。

斯蒂芬T。拉瓦维

Visual C++库开发人员