How to make std::vector's operator[] compile doing bounds checking in DEBUG but not in RELEASE

Question

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).

Answer 1

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)

Answer 2

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

Answer 3

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.

Answer 4

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().. :-(

Answer 5

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.