Visual Studio debug iterators

Question

Cuál es la relación entre _SECURE_SCL y _HAS_ITERATOR_DEBUGGING. ¿Es posible activar/desactivar la comprobación de rango y preservar la compatibilidad binaria?

¿Alguna diferencia entre las versiones de 2008 y 2010?

Answer 1

Stephan Lavavej ha proporcionado algunos detalles sobre este _SECURE_SCL y _HAS_ITERATOR_DEBUGGING:

De http://blogs.msdn.com/b/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx

depuración iterador, habilitado por _HAS_ITERATOR_DEBUGGING, lleva a cabo la verificación de gran alcance corrección. La verificación del iterador, habilitada por _SECURE_SCL, realiza comprobaciones mínimas que sirven como última línea de defensa . Por ejemplo, _SECURE_SCL terminará un programa que desencadena un desbordamiento de pila con un iterador vectorial.

Todo lo que se explica por la documentación de MSDN . La historia detrás de este es interesante. La funcionalidad _HAS_ITERATOR_DEBUGGING fue proporcionada por Dinkumware, la compañía que otorga la licencia de su implementación más triunfante de la Biblioteca estándar para su inclusión en Visual Studio. La funcionalidad _SECURE_SCL fue agregada por Microsoft, para mejorar la seguridad de los programas que se ejecutan en Windows. Para que realicen sus comprobaciones, tanto _HAS_ITERATOR_DEBUGGING como _SECURE_SCL hacen que los iteradores hagan que los iteradores contengan miembros de datos adicionales, como punteros a sus contenedores principales. _HAS_ITERATOR_DEBUGGING, porque está habilitado de manera predeterminada en modo de depuración (y no se puede obtener en modo de lanzamiento), también crea listas unidas que permiten que los contenedores hagan referencia a todos sus iteradores . Esto es caro en cuanto al rendimiento, pero el rendimiento es no crítico en el modo de depuración, y este permite comprobaciones excelentes.

_SECURE_SCL, porque está habilitado de manera predeterminada en el modo de lanzamiento, se esfuerza por imponer penalizaciones de rendimiento mínimas. Por lo tanto, cuando está habilitado, aunque los iteradores tienen punteros a sus contenedores, los contenedores no tienen punteros a sus iteradores. (actualización "listas de iterador" es demasiado tiempo para el modo de liberación.)

Tenga en cuenta que a partir de VS 2010, _SECURE_SCL ya no está activado por defecto en el modo de disparo (la cita anterior es de 2007).

Como se describe en este informe de error (http://connect.microsoft.com/VisualStudio/feedback/details/334315/has-iterator-debugging-0-causes-crash), ambos _SECURE_SCL y _HAS_ITERATOR_DEBUGGING afectan el ABI:

_SECURE_SCL y _HAS_ITERATOR_DEBUGGING significativamente cambiar el comportamiento y representaciones de contenedores STL y iteradores.VC9 (Visual Studio 2008) hizo que las representaciones de contenedores e iteradores STL incluso más dependieran fuertemente de _SECURE_SCL y _HAS_ITERATOR_DEBUGGING (esto se hizo para corregir un error de conformidad).

Debido a estas macros cambian las representaciones de objetos STL, que debe observar ciertas reglas cuando cambiar estas macros de sus valores predeterminados. He descrito aquí las reglas: http://blogs.msdn.com/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx#4617984 En resumen, las macros deben ser consistentes dentro de cada binario (EXE o DLL ), y además, binarios que pase STL objetos entre sí imprescindible tienen valores de la macro consistentes. Su ejemplo implica un EXE y DLL pasando un vector entre , por lo que el EXE y el DLL necesitan tener la misma configuración _SECURE_SCL y _HAS_ITERATOR_DEBUGGING.

Estas reglas se aplican a las versiones futuras de VC8, VC9 y todas las . Su código pasó a trabajar con VC8 (Visual Studio 2005), , pero fallaría si hiciera más cosas complicadas de .