runtime error with vector

When i run my code and type in a number into a variable and then check my vector to see if that number is present and if so delete it. However i keep getting an error with this segment of code spedifically the if statement.

Code:

---

        cin >> Age;
       
        for(unsigned int i=0;i<=(names.size());i++)
        {
                if(names[i]==Age)
                {
                        names.erase((names.begin() + i));
                        break;
                }
        }

---

The vector has the numbers 1,2,3,4 inside and when i run the code if i enter 2i get a runtime error saying the vector subscript is out of range? any ideas?

Do you also get the error if you do i < names.size() instead?

Consider using at() instead of operator[] for vector access by index. That way you're guaranteed that an exception is thrown so that if you make such mistakes later they will be more obvious. Using operator[] like that means anything can happen if you overstep the bounds of the vector.

I see little benefit in using at() since it obviously has more overhead. When an out of bounds vector access is performed it is very clear to the programmer what happened. The error message is not vague and the error is easy to fix. The OP even says that the error is 'vector subscript out of range'. That's a very clear error and much clearer than usual for any template-based error. Proper use of the vector is the problem here and not so much the use of the array access operator.

Its beter to use the at() method cause [] operetor inserts null or the value provided on the specefied index if it doesnt exist. so for reading purpouse using at(0 is recomended.
However while using you should use vector Iterators.
I am assuming that Age is string and names is vector of strings too.

Code:

---

vector<string>::iterator it;
cin>>age;
for(it=names.begin();it < names.end();it++){
  if(*it == age){
    names.erase(it);
  }
}

---

if names is an int vector not a strings vector use atoi() on age to convert it to int

No, operator [] does not insert for vector.
Using operator [] for an index that does not exist results in undefined behavior.
Unfortunately, there's no way to use an .at() function that return false or fails silently if it fails instead of throwing.
Otherwise I would always use some kind of assert or safe function; otherwise we're just back to plain old unsafe C.

Quote:

---

Originally Posted by Elysia

No, operator [] does not insert for vector

---

Nope It does Insert an element on that Position if doesnt exist. I am not asking you to belief my words just compile this Program and see its output.
http://pastebin.com/f77cf1921

Code:

---

#include <iostream>
#include <vector>
#include <cstdlib>

using std::cout;
using std::endl;
using std::vector;

int main(int argc, char** argv){
        vector<int> v;
        v.push_back(5);
        v.push_back(10);
        cout<<"Inserting"<<endl;
        cout<<v[0]<<endl<<v[1]<<endl<<v[2]<<endl<<v[3]<<endl;
        return EXIT_SUCCESS;
}

---

Quote:

---

Originally Posted by Elysia

Using operator [] for an index that does not exist results in undefined behavior.

---

Its not UNDEFINED behaviour the behaviour is well defined that it will insert an element on that index

Quote:

---

Originally Posted by Elysia

Unfortunately, there's no way to use an .at() function that return false or fails silently if it fails instead of throwing.

---

So ? Whats wrong with Exceptions ?? I think try catch block is more sturctured than returning false and something like that.
and at() returns an element so if it returns false or 0x0 or 0 or -1 or null
WOULDNT YOU THINK THAT THIS IS THE VALUE IN THAT POSITION

Quote:

---

However while using you should use vector Iterators.

---

Unfortunately your example is wrong... Erase invalidates the iterator you are using to iterate the loop.
Therefore, if possible you should look into using the standard algorithms :). Your example could be corrected as:

Code:

---

//remove all items that are equal to age
names.erase(remove(names.begin(), names.end(), age), names.end());

---

And OP's example could be corrected to:

Code:

---

//erase the first occurrence of age
names.erase(find(names.begin(), names.end(), age));

---

And if you want/need to write manual loops, you should simply remember that in idiomatic C++ all ranges are up to but not including the last index. Therefore you should practically never need the <= operator to loop over a range (use <, or more generally !=).

Quote:

---

Its not UNDEFINED behaviour the behaviour is well defined that it will insert an element on that index

---

Definitely undefined with vector.

(Although I'm not too happy about at(): 99.99&#37; of use cases the range check is completely redundant - once the code is not giving you any troubles.)

Quote:

---

Originally Posted by anon

Unfortunately your example is wrong... Erase invalidates the iterator you are using to iterate the loop.
Therefore, if possible you should look into using the standard algorithms :).

---

So what ? It erases the entry thats age matches with the value.what he will do with that iterator after erasing the thing is not a part of the example.
that example Compiles and run.
http://pastebin.com/f306d7d4a

Code:

---

#include <iostream>
#include <vector>
#include <cstdlib>
#include <string>

using std::cout;
using std::cin;
using std::endl;
using std::vector;
using std::string;

int main(int argc, char** argv){
        vector<string> names;
        names.push_back("5");
        names.push_back("10");
        names.push_back("15");
        string age;
        vector<string>::iterator it;
        cin>>age;
        for(it=names.begin();it < names.end();it++){
          if(*it == age){
            names.erase(it);
          }
        }
        for(it=names.begin();it<names.end();it++){
          cout<<*it<<endl;
        }
        return EXIT_SUCCESS;
}

---

Quote:

---

Originally Posted by anon

Therefore you should practically never need the <= operator to loop over a range (use <, or more generally !=

---

using < and != doesnt make any difference and its personal favoures of people and it varies man to man and there is nothing impratical or wrong or bad in any of this <= or < or != untill it matches the algorithm.

Sorry but your example is slightly wrong. Try this small modification and input 5. It should remove all 5-s, shouldn't it? But it doesn't! After each erasure you skip one item - and if you skip the last you may well increment names.end() and enter undefined land.

Code:

---

#include <iostream>
#include <vector>
#include <cstdlib>
#include <string>

using std::cout;
using std::cin;
using std::endl;
using std::vector;
using std::string;

int main(int argc, char** argv){
        vector<string> names;
        names.push_back("5");
        names.push_back("5");
        names.push_back("15");
        string age;
        vector<string>::iterator it;
        cin>>age;
        for(it=names.begin();it < names.end();it++){
          if(*it == age){
            names.erase(it);
          }
        }
        for(it=names.begin();it<names.end();it++){
          cout<<*it<<endl;
        }
        return EXIT_SUCCESS;
}

---

For your information, undefined behaviour doesn't mean that the program will crash or do otherwise an obviously wrong thing. Undefined behaviour means that your program may appear to work correctly - until the slightest change in any unrelated part of the program. You may get away with out-of-bound accesses unpunished, for example because the vector overallocates and that memory still belongs to it, although it is unused.

That is, you have to know what you are doing.

As to whether [] inserts for vector, would it be that hard to find out:

Code:

---

#include <iostream>
#include <vector>

int main()
{
    std::vector<int> v;
    v.reserve(2);
    v[0] = 10;
    std::cout << v.size();
}

---

This should print (at least) 1 according to your theory, but the vector nevertheless reports that it contains 0 items. This code just accesses an item out of the vector's bounds (and it probably gets away with it, since that memory is reserved - not making this code correct, though).

As to correcting your erase example, try this:

Code:

---

#include <iostream>
#include <vector>
#include <cstdlib>
#include <string>

using std::cout;
using std::cin;
using std::endl;
using std::vector;
using std::string;

int main(int argc, char** argv){
        vector<string> names;
        names.push_back("5");
        names.push_back("5");
        names.push_back("15");
        string age;
        vector<string>::iterator it;
        cin>>age;

        for(it=names.begin();it < names.end();){
          if(*it == age){
            it = names.erase(it);
          }
          else {
            ++it;
          }
        }

        for(it=names.begin();it<names.end();it++){
          cout<<*it<<endl;
        }
        return EXIT_SUCCESS;
}

---

As you can see the loop is not as trivial as that. Therefore it is a better idea to use std algorithms for such tasks (particularly since the erase-remove combo has better complexity and does a lot less copying for larger datasets).

Quote:

---

input 5. It should remove all 5-s, shouldn't it? But it doesn't!

---

according to the original Code from te5la which uses break means he want to remove the first only so It doesnt need to care about all other matches.
operator[] will insert an item if that position is blank

http://pastebin.com/f6f987ea4

Code:

---

#include <iostream>
#include <vector>
#include <cstdlib>
 
using std::cout;
using std::endl;
using std::vector;
 
int main(int argc, char** argv){
        vector<int> v;
        v.push_back(5);
        v.push_back(10);
        cout<<"Inserting"<<endl;
        cout<<v[0]<<endl<<v[1]<<endl<<v[2]<<endl<<v[3]<<endl<<v[4]<<endl;
        cout<<"Printing"<<endl;
        cout<<v[4]<<endl;//v[4] has a value and its being printed which means [] operator has inserted it
        return EXIT_SUCCESS;
}

---

Run the above program and see that when I am just calling v[2], v[3], v[4] Its inserting null/junk values in it.and while doing cout<<v[4] Its showing up that too.

Quote:

---

Originally Posted by noobcpp

Nope It does Insert an element on that Position if doesnt exist. I am not asking you to belief my words just compile this Program and see its output.

---

It does no such thing. And the output of your program is irrelevant. The behavior is UNDEFINED, meaning anything could happen, including appearing to work correctly.

But in 99&#37; cases it does insert.
doesnt matter it inserts or not doesnt its behaviour is undefined ort not. when one is only accessing values one should use at() instead of using operator[] cause operator[] is used both for get and set operation and at() is used only for get operation so its beter to limit the scope to only get values and use at()

You cannot be a good C/C++ programmer if you have an inability to accept it when you find out something results in undefined behavior.

Quote:

---

Originally Posted by noobcpp

But in 99&#37; cases it does insert.
doesnt matter it inserts or not doesnt its behaviour is undefined ort not. when one is only accessing values one should use at() instead of using operator[] cause operator[] is used both for get and set operation and at() is used only for get operation so its beter to limit the scope to only get values and use at()

---

Is it so hard to get it into your thick skull?
OPERATOR [] DOES NOT INSERT ANYTHING.
What you is random junk (aka, undefined behavior!).
It's the same as doing:

Code:

---

int myarray[2];
cout << myarray[3] << endl;

---

Thanks alot guys this has helped a great deal! much appreciated

Btw, for anyone interested, here's what I get with the undefined code:

Inserting
5
10
-33686019
0
459177
Printing
458760

What I find curious is this:

cout<<v[0]<<endl<<v[1]<<endl<<v[2]<<endl<<v[3]<<endl<<v[4]<<endl;
cout<<"Printing"<<endl;
cout<<v[4]<<endl;//v[4] has a value and its being printed which means [] operator has inserted it

It prints the same element twice, yet got different results.
And I suggest that anyone who thinks it is NOT undefined code, takes a look inside the ACTUAL code for vector.

I took a look at the code and it looks like this:

Code:

---

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

---

_Myfirst is a pointer of type int*. Does that insert a value?
If it does, then I don't see how.
Blam! Rumor smashed. Operator [] does not insert.

Code:

---

#include <iostream>
#include <vector>

int main()
{
        std::vector<std::string> v;
       
        //v.resize(1001);
        v[1000] = "Some random string.";
        std::cout << "v[1000] = " << v[1000] << std::endl;
       
        return 0;
}

---

Oh, look. This crashes for me. I'm shocked. I'm also being sarcastic.

If it's not undefined, why does it crash?

>> I see little benefit in using at() since it obviously has more overhead.
This would be a premature optimization, IMO, at least in most programs.

>> The error message is not vague and the error is easy to fix.
It's undefined behavior. The OP got lucky with an easy to understand error message because of his or her platform (which is probably doing range-checking on operator[] anyway meaning at() adds no overhead). It might appear to work but give incorrect data to your program, which is why I suggested that at() be considered.


>> according to the original Code from te5la which uses break means he want to remove the
>> first only so It doesnt need to care about all other matches.
noobcpp, your iterator example did not break when it found a match, so either it is wrong because it doesn't follow the OP's use case or it is wrong because it fails to delete all values. Either way it is wrong (in fact, it could lead to accessing an iterator after end() which is also quite bad).

And as has been noted vector does not insert when you use operator[] (although std::map does). Please be careful to not give such blatantly wrong information in the future, it can be very confusing for the person just looking for a simple answer.

Well.... to give new input to this passionate discussion: let's have a look at the "vector" header file! It's open source, so you can just look it up. (please do so, noobcpp!).

Code:

---

      // 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 *(this->_M_impl._M_start + __n); }

      /**
      *  @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-only (constant) 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().)
      */
      const_reference
      operator[](size_type __n) const
      { return *(this->_M_impl._M_start + __n); }

---

(ps: this also should be stated in the Doxygen documentation of STL)

And this is what "at()" does:

Code:

---

      /// Safety check used only from at().
      void
      _M_range_check(size_type __n) const
      {
        if (__n >= this->size())
          __throw_out_of_range(__N("vector::_M_range_check"));
      }

---

And finally, tratatatata............ the function "at()" :

Code:

---

      /**
      *  @brief  Provides 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.
      *  @throw  std::out_of_range  If @a n is an invalid index.
      *
      *  This function provides for safer data access.  The parameter
      *  is first checked that it is in the range of the vector.  The
      *  function throws out_of_range if the check fails.
      */
      reference
      at(size_type __n)
      {
        _M_range_check(__n);
        return (*this)[__n];
      }

      /**
      *  @brief  Provides access to the data contained in the %vector.
      *  @param n The index of the element for which data should be
      *  accessed.
      *  @return  Read-only (constant) reference to data.
      *  @throw  std::out_of_range  If @a n is an invalid index.
      *
      *  This function provides for safer data access.  The parameter
      *  is first checked that it is in the range of the vector.  The
      *  function throws out_of_range if the check fails.
      */
      const_reference
      at(size_type __n) const
      {
        _M_range_check(__n);
        return (*this)[__n];
      }

---

Now guess what: "reference" and "const_reference" are typedefs for allocators:

Code:

---

      typedef typename _Tp_alloc_type::reference        reference;

---

which means simply that one can write an element with the function "at()" (again erroneous information, noobcpp!)

ps: Isn't this poetry at it's most beautiful... :-)

>> let's have a look at the "vector" header file
Of course, that's just one implementation. The final say is the standard, but this is such a simple and obvious point that everybody but noobcpp agrees on that I don't plan to look up the relevant text.

Quote:

---

>> I see little benefit in using at() since it obviously has more overhead.
This would be a premature optimization, IMO, at least in most programs.

---

Yes after posting that I realized this argument was not the best and it's not exactly what I was trying to say. By no means would extra at()'s hurt performance and not all apps even care about top performance. So I will certainly retract this statement and restate it as - I prefer to use array access but probably have no good reason for doing so other than pure habit. :D

Quote:

---

>> The error message is not vague and the error is easy to fix.
It's undefined behavior. The OP got lucky with an easy to understand error message because of his or her platform (which is probably doing range-checking on operator[] anyway meaning at() adds no overhead). It might appear to work but give incorrect data to your program, which is why I suggested that at() be considered.

---

I think my point was the root of the problem was not necessarily the use of the array access operator but it was the misuse of it - IE: using it with an out of bounds index. Using at() would ensure you were in-bounds but I guess I'm coming from the mindset of you should know if you are in bounds or not. So the bottom line is this is a complete misuse of size() and of vector. I also don't want to project the notion that using at() is more valid than using array access or vice versa b/c both those arguments are quite absurd. It comes down to a choice on the programmer's part and if he/she uses their chosen method correctly they should have no troubles. I am certainly not condoning the use of code that produces undefined behavior. In the end I think most of us, minus a few, are saying the same thing.

I dont want to argue

Quote:

---

Originally Posted by MacGyver

Code:

---

#include <iostream>
#include <vector>

int main()
{
        std::vector<std::string> v;
       
        //v.resize(1001);
        v[1000] = "Some random string.";
        std::cout << "v[1000] = " << v[1000] << std::endl;
       
        return 0;
}

---

Oh, look. This crashes for me. I'm shocked. I'm also being sarcastic.

If it's not undefined, why does it crash?

---

Its a vector not a Map so it must mantain a sequence and when 0, 1, 2 ..... is not present you cnt insert an element on 1000 so it crashed.
it can also happen that it crashed cause it tried to insert but failed.

PLESE READ THE FULL POST

But in most of the cases it inserts or at least it tries to insert. If one is stuck to say undefined behaviour Cant we put
"trying to inserting an Item and failing" and
"successfully Inserting an Item" and
"Wrongly inserting an Item" and
"inserting 0" and
"inserting junk" and
"crashing if jumped too far away indexes"
all this posibilities together in the list of undefined behaviours ??

However in vector its numarically and sequentialy indexed where as in map its not and in case of map's operator[]() it inserts a new element on the non existing node. (which is stated in documentation)
and so in case vector also it tries to insert which leads undefined befaviour

noobcpp: Just on the off hand that yet one more pseron telling you that you are wrong will make a difference:
The [] operator for a vector does not insert - EVER!!!
The [] operator for a map does insert if the item does not already exist.
The push_back method for a vector will insert one more item at the end of the vector.

If you don't want to argue then stop posting nonsense. Of course people will disagree with false statements. It's in your best interests to do some research, realise you were wrong, swallow your pride, and actually learn something. That is if you'd perfer to stop making yourself look stupid.

Again, vector does not insert. Ever.
We have showed you two possible implementations, of which neither tried to insert anything.
The standard says it's undefined, because access an out-of-bounds element is undefined.
On other other hand, Microsoft's code also looks for out-of-range and throws or raises an assert if out-of-bounds happens because the standard does not say what happens if you do out of bounds.

However, if you think that operator [] will insert, you are fatefully mistaken. We will most likely (99&#37; sure) that we will NEVER see such an implementation.

It tries to access an out-of-bounds element, which leads to undefined behavior. That's all.

>> I guess I'm coming from the mindset of you should know if you are in bounds or not.
Understood. I honestly don't use at() myself. However, for someone having trouble knowing if they are in bounds or not, then it can be a good tool with few (if any) drawbacks. I think ideally I would move to using at() myself for non-performance critical operations, but I'm too stuck in the C style array habit to make the change.

Quote:

---

Originally Posted by noobcpp

But in most of the cases it inserts or at least it tries to insert.

---

No. It doesn't.

Oh, and btw.... as far as vector's go, "insert" is not the same as "trashes arbitrary memory in an undefined manner."