Cómo hacer que el operador de std :: vector compile haciendo límites comprobando en DEPURAR pero no en LIBERACIÓN

Estoy usando Visual Studio 2008.

Soy consciente de que std :: vector tiene límites de comprobación con la función at () y tiene un comportamiento indefinido si intenta acceder a algo utilizando el operador [] incorrectamente (fuera de rango).

Tengo curiosidad si es posible comstackr mi progtwig con la comprobación de límites. De esta forma, el operador [] usaría la función at () y arrojaría un std :: out_of_range siempre que algo esté fuera de límites.

El modo de lanzamiento se comstackría sin límites para el operador [], por lo que el rendimiento no se degrada.

Empecé a pensar en esto porque estoy migrando una aplicación que se escribió usando Borland C ++ a Visual Studio y en una pequeña parte del código tengo esto (con i = 0, j = 1):

v[i][j]; //v is a std::vector<std::vector > 

El tamaño del vector ‘v’ es [0] [1] (por lo que el elemento 0 del vector tiene solo un elemento). Este es un comportamiento indefinido, lo sé, pero Borland está regresando 0 aquí, VS está fallando. Me gusta más el locking que devolver 0, así que si puedo obtener más ‘fallas’ mediante la excepción std :: out_of_range que se lanza, la migración se completará más rápido (para que quede al descubierto más errores que Borland estaba ocultando).

Visual Studio 2005 y 2008 ya hacen check-bounds en el operator[] de forma predeterminada, tanto en versiones de depuración como de versiones.

La macro para controlar este comportamiento es _SECURE_SCL . Establézcalo en 0 para deshabilitar la comprobación de límites.

Su plan actual en VS2010 es desactivar la comprobación de límites por defecto en las comstackciones de lanzamiento, pero mantenerlo en depuración. (La macro también se renombró a _ITERATOR_DEBUG_LEVEL . No sé si todavía hay documentación formal disponible, pero se ha mencionado aquí y aquí )

Habilite el indicador _GLIBCXX_DEBUG para que verifique los límites en contenedores STL, como se explica aquí: http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html

Pregunté esto demasiado prematuramente, pero estoy publicando la respuesta de todos modos, así que estoy compartiendo algunos conocimientos.

El stl implementado en Visual Studio ya hace la comprobación de los límites al comstackr en modo Debug. Esto se puede ver en el encabezado :

 reference operator[](size_type _Pos) { // subscript mutable sequence #if _HAS_ITERATOR_DEBUGGING if (size() <= _Pos) { _DEBUG_ERROR("vector subscript out of range"); _SCL_SECURE_OUT_OF_RANGE; } #endif /* _HAS_ITERATOR_DEBUGGING */ _SCL_SECURE_VALIDATE_RANGE(_Pos < size()); return (*(_Myfirst + _Pos)); } 

entonces hay límites verificando la clase vectorial. No miré otros contenedores, pero estoy seguro de que tienen el mismo mecanismo.

No tengo acceso a ninguna máquina de Windows en este momento. Pero si analizo la implementación de STL entregada con g ++ en mi máquina mac os x, desde /usr/include/c++/4.0.0/bits/stl_vector.h:

  // element access /** * @brief Subscript access to the data contained in the %vector. * @param n The index of the element for which data should be * accessed. * @return Read/write reference to data. * * This operator allows for easy, array-style, data access. * Note that data access with this operator is unchecked and * out_of_range lookups are not defined. (For checked lookups * see at().) */ reference operator[](size_type __n) { return *(begin() + __n); } 

No se realizó ninguna comprobación, aunque el evento en modo DEBUG. No _GLIBCXX_DEBUG marcro está desprotegido aquí en este código.

Eche un vistazo a su propia implementación de STL entregada con MSVC y vea lo que se hace. Si no se realiza ningún control en ningún caso … no tiene más remedio que usar at () .. 🙁

C ++ define vector operador [] como no lanzando excepción en aras de la velocidad.

Te aconsejo que pruebes la aplicación en Debug Configuration por un tiempo hasta que ganes la confianza de que los principales errores “ocultos” desaparecieron.

    Intereting Posts