Bug on STL Vector assignment operator

Posted in C/C++ LANGUAGE, PROGRAMMING by edeguzman on April 21, 2009

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

Advertisements

2 Responses

Subscribe to comments with RSS.

  1. pizer said, on April 21, 2009 at 11:35 am

    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. edeguzman said, on April 22, 2009 at 3:01 am

    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

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: