保卫C++：安全STL编程中的受检迭代子
C++语言、STL、标准C++库，相比之C语言及C运行时库(CRT)而言，更加现代、也更加健壮。正因为软件的安全性与健壮性息息相关，所以在安全性方面，标准C++比C及CRT面临的问题更少，那也就不足为奇了。然而，在标准C++中，仍存在一些漏洞，而且，Visual C++ 2005中的一项新增功能，使这个所谓的“循环漏洞”更加轻易被忽视。
STL在横向集合中，大量使用了迭代子(iterator)，对迭代子不正确的使用，一般可以两种主要的方式表现出来:
·使用已被集合修改为无效的迭代子
·使用迭代子试图访问集合范围之外的一个元素
以下的代码演示了这两种问题:
//使用一个无效的迭代子
vector vec;
vec.push_back(1);
std::vector::iterator it = vec.begin();
vec.push_back(2);
std::cout<<*it;
//试图访问迭代子范围之外
vector emptyVec;
std::vector::iterator emptyIt = emptyVec.begin();
int i = *emptyIt;
假如在Visual C++ 2005中，以Debug方式来构建上述代码，这两种情况都会引发断言错误，所以要找到错误所在，并不是很难;假如以Release方式来构建，将不会捕捉到对无效迭代子的使用，但仍会捕捉到对集合外部数据的访问。原因在于，Debug构建基于Visual C++中被称为“调试迭代子支持”的那一部分，其是通过在运行时库源代码中进行检查来实现的，而在默认情况下，Debug构建时是打开“调试迭代子支持”的，但你也能通过把符号_HAS_ITERATOR_DEBUGGING定义为一个零值来关闭它。
“调试迭代子支持”——其主要集中在代码正确性上，与之形成对比的是，Release构建概念中的受检迭代子，其主要集中在防止程序运行中的安全问题。当有错误发生时，受检迭代子通常产生一个运行时错误，默认情况下会终止程序，而不是抛出一个断言。一般来说，可以有两种方法来处理由受检迭代子产生的错误:
·调用_set_invalid_parameter_handler，来设置一个非法参数处理程序。
·定义_SECURE_SCL_THROWS为1，其在抛出时导致一个异常。
另外，为强制Visual C++与C++标准保持一致，并且不对迭代子进行检查，你可以把_SECURE_SCL定义为零。
受检查迭代子适用于大多数STL容器类中的[ ]操作符，front和back方法;正因为算法在STL中扮演了一个重要的角色，所以与受检迭代子进行集成，无疑对它们来说显得至关重要。而在Microsoft安全部署中，最重要的一点就是，编译器要在默认情况下打开安全选项，这也是受检迭代子与STL算法中这些迭代子的使用情况。对一个使用了受检迭代子的程序而言，所有对标准算法函数的调用，都会导致一个安全函数被调用，这意味着，假如调用一个std::merge，将会转发至stdext::checked_merge。而在STL算法中，这些加有checked_ 前缀的版本防止了未受检的迭代子，当使用第三方且是未用Visual C++ 2005重新编译过的的组件时，就可以捕捉到这些未受检迭代子了，任何试图传递一个未受检迭代子到受检算法中的代码，都不会通过编译。
Visual C++的安全增强与语言标准
在以前，Microsoft公司为了其自己的种种商业利益，在很长一段时间里忽视或暗中搅乱C++语言的标准化进程;如今，Microsoft在许多的标准实体中，都扮演了一个重要且有帮助性的角色，作为一家在C++方面投资最大的公司，参与到“标准化”这个游戏当中来，无疑非常引人注目。
C++/CLI如今已是一个ECMA标准，这意味着(如同标准C++一样)，任何编译器开发商都可以构建一个C++/CLI语言编译器。一个特定的C++/CLI编译器可能会专注于CLR或一个完全不同的环境，如Java的运行时库;另外，对C++/CLI的反对声音，宣称因为基于C++/CLI与标准C++太过于不同，因此需要另外一个不同的名字。争论的核心在于“C++/CLI已发展成为一个差不多、但又不完全不像我们所知的C++的语言，语法、语义、术语及底层对象模型，都大不相同。”但这个反对声音并不奏效，如今C++/CLI已是一个完整版本的语言了。
当前，Microsoft仍通过C标准化过程，着手对CRT的安全性进行修改，假如且当这些修改被认可，及Visual C++ 2005中带 _s后缀的函数与Visual C++合成一体时，那么使用CRT编写可移植及更安全的代码，就不再是空中楼阁了。
最后，在Visual C++ 2005中并没有强制使用这些安全扩展或C++/CLI，假如你喜欢设置不同的#define，或者在某些情况中忽略编译器的警告，那么，纯净、无瑕疵的C/C++代码就正在向你招手。
