views:

1049

answers:

5

I'm using Visual Studio 2008.

I'm aware that std::vector has bounds checking with the at() function and has undefined behaviour if you try to access something using the operator [] incorrectly (out of range).

I'm curious if it's possible to compile my program with the bounds checking. This way the operator[] would use the at() function and throw a std::out_of_range whenever something is out of bounds.

The release mode would be compiled without bounds checking for operator[], so the performance doesn't degrade.

I came into thinking about this because I'm migrating an app that was written using Borland C++ to Visual Studio and in a small part of the code I have this (with i=0, j=1):

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

The size of the vector 'v' is [0][1] (so element 0 of the vector has only one element). This is undefined behaviour, I know, but Borland is returning 0 here, VS is crashing. I like the crash better than returning 0, so if I can get more 'crashes' by the std::out_of_range exception being thrown, the migration would be completed faster (so it would expose more bugs that Borland was hiding).

A: 

C++ defines vector operator[] as not throwing exception for sake of speed.

I'd advise you to test the application in Debug Configuration for a while till you gain confidence that major "hidden" bugs gone.

dimba
C++ leaves it undefined what happens if [] goes out of bounds. That means it is legal for an implementation to perform bounds checking, and some do.
jalf
+1  A: 

I asked this too prematurely, but I'm posting the answer anyway so I'm sharing some knowledge.

The stl implemented in Visual Studio already do bounds checking when compiling in Debug mode. This can be seen at the <vector> header:

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));
     }

so there is the bounds checking for the vector class. I didn't look at other containers, but I'm confident that they have the same mechanism.

Edison Gustavo Muenz
uhuh. You were quikier than me on this post ;-)
yves Baumes
Same here :) That said, I *am* pretty sure that it continues to do this check even in Release. There is a macro you must define to turn it off completely.
GMan
yep, see my post
jalf
Indeed, jalf to the rescue.
GMan
+1  A: 

I don't have access to any windows machine right now. But if I look into the STL implementation delivered with g++ on my mac os x machine, from /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 check performed, event though in DEBUG mode. No _GLIBCXX_DEBUG marcro is checked out here in this code.

Have a look in your own STL implementation delivered with MSVC and see what is done. If no check are peformed in any case ... you have no choice but using at().. :-(

yves Baumes
MSVC does perform bounds checking by default (in VC8 and 9 *both* in debug and release builds, in VC10 only in debug)
jalf
+11  A: 

Visual Studio 2005 and 2008 already do bounds-checking on operator[] by default, in both debug and release builds.

The macro to control this behavior is _SECURE_SCL. Set it to 0 to disable bounds-checking.

Their current plan in VS2010 is to disable bounds-checking by default in release builds, but keep it on in debug. (The macro is also getting renamed to _ITERATOR_DEBUG_LEVEL. I don't know if there's any formal documentation available on it yet, but it has been mentioned here and here)

jalf
+1 Perfect. Where would you find out stuff like the new name? Just look in the new header files?
GMan
just updated with some more info
jalf
Thank you! [15char]
GMan
Just be sure that you use _SECURE_SCL consistently. Inconsistent use will cause undefined behaviour aka crash.
Stephen Nutt
A: 

Enable the flag _GLIBCXX_DEBUG to do bounds checking on STL containers, as discussed here: http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html

amos