Bug on STL Vector assignment operator

2009 April 21

STL Vector is considered to be an alternative to a C-based style Array. It is more robust and less error-prone compare to the standard array. Standard array subscripts can fall outside of its range while the STL vector can detect error on its subscript falling outside of its range. Assignment operation (=) cannot be apply in Standard array while in STL vector it can be apply. Another advantage of STL vector is the passing of arguments to a function call, in standard array passing of arguments in function call requires you also to pass the array size but in STL vector does not requires the size. Those are the fundamental advantage of STL vector to the standard array.

As I was doing a program and I was using the STL vector there were two bugs that I found on STL vector, I considered them bugs for me because I believe its not on my code anymore. I spent almost an hour debugging on my program and only to find out that it was the vector that’s doing the bug.

I post these bug for you people to be aware of it if ever you will be
using the STL vector. Or if ever I’m wrong with these bugs I would really appreciate if you guys help figure out these errors.

Below is the sample code that I come up to present to you the bug on assignment operator (=). First part shows the basic use of vector.


#include<iostream>
#include<vector>

using std::vector;

int main ()
{
vector<int> test(2);

test[0] = 100;
test[1] = 200;
test[2] = 300;

std::cout<<”test[0] value = “<<test[0]<<std::endl;
std::cout<<”test[1] value = “<<test[1]<<std::endl;
std::cout<<”test[2] value = “<<test[2]<<std::endl;

return 0;
}

OUTPUT :
no bug

The above code shows vector having no bug on it. Now I modify the code with the assigment operator.


#include<iostream>
#include<vector>

using std::vector;

int main ()
{
vector<int> test(2);
vector<int> var(2);

test[0] = 100;
test[1] = 200;
test[2] = 300;
var = test;
std::cout<<”test[0] value = “<<std::endl;
std::cout<<”test[1] value = “<<std::endl;
std::cout<<”test[2] value = “<<std::endl;

std::cout<<”\nvar[0] value = “<<std::endl;
std::cout<<”var[1] value = “<<std::endl;
std::cout<<”var[2] value = “<<std::endl;

return 0;
}

OUTPUT :
bug found

As you can see on the output, it shows that the last subscript index of variable test had change its value to 100. It seems to me that it did copy the test[0] value to test[2], which should be happen. Another bug you might notice is on the last subscript index of variable var,in which the value has initialize to 0 and not to value 300. If you’re going to compare in conditional statement (==) to between variable test and var, the conditional statement will yield to true despite the fact that the entries of vector variable test and var is different.

If anyone of you guys disagree please explain to me why this such happen or what’s the explanation behind of it. I also did check the memory address between vector variable test and var, and it shows they are on a different memory location.

cheers =)

2 Responses leave one →
  1. 2009 April 21

    The C++ standard doesn’t enforce array bounds checking for operator[] but it enforces array bounds checking for the function “at”. If you use “at” instead you’ll notice that you’re actually accessing the vector with an invalid index 2. The vector has size 2 and thus only the elements at(0) and at(1) are valid but at(2) is not.

    What happened is that you wrote into the wild memory and got away with it but wondered why the vector didn’t copy the “last” element. Well, it did copy the last element. But the last element was “200″ because test.size()==2.

  2. 2009 April 22

    I get it now. Thanks for your response. It was my mistake so far, I thought that vector doesn’t provide for null at the last element just like the standard array does.
    From the way I see it that the error checking of vector for subscripts going outside of range is from the null itself at the last element.

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS