No out_of_range exception for "iterator + n" vs. vector.at( n )

[Mike Austin]

Hi all. Just working on a small virtual machine, and thought about using
vector iterators instead of pointer arithmetic. Question is, why does an
iterator plus any number out of range not generate a out_of_range exception?
Maybe this is a gcc issue?

I'm using gcc version 3.3.3 (cygwin special).

Here's the full sample code:

#include <iostream>
#include <vector>
#include <stdexcept>
using namespace std;

int main() {
vector<int> code;
code.push_back( 10L );
code.push_back( 20L );

vector<int>::it erator iter = code.begin();
try {
cout << *(iter + 5) << endl; // 0
cout << code.at( 10 ) << endl; // vector [] access out of range
} catch( out_of_range e ) {
cout << e.what() << endl;
}

return 0;
}
Thanks,
Mike

[Mike Wahler]

"Mike Austin" <mi**@mike-austin.com> wrote in message
news:0L******** *************@b gtnsc04-news.ops.worldn et.att.net...

Hi all. Just working on a small virtual machine, and thought about using
vector iterators instead of pointer arithmetic. Question is, why does an
iterator plus any number out of range not generate a out_of_range exception?

Because that's the way the library is designed.
If you want range checking, use vector::at().
That's what it's for.

This follows the "don't pay for what you don't use"
principle of C++. ('at()' will necessarily add more
overhead which might be unacceptable for some
applications).
Maybe this is a gcc issue?
No.
I'm using gcc version 3.3.3 (cygwin special).

Here's the full sample code:

#include <iostream>
#include <vector>
#include <stdexcept>
using namespace std;

int main() {
vector<int> code;
code.push_back( 10L );
code.push_back( 20L );

vector<int>::it erator iter = code.begin();
try {
cout << *(iter + 5) << endl; // 0
I don't know what you mean by your comment "0",
but note that this statement produces 'undefined behavior'.
cout << code.at( 10 ) << endl; // vector [] access out of range
} catch( out_of_range e ) {
cout << e.what() << endl;
}

return 0;
}

If you don't use the protection of 'vector::at()' you can still protect
yourself by checking e.g. 'vector::size() ', 'vector::empty( )', comparing
against 'vector::end()' , etc.

-Mike

[Mike Wahler]

"Mike Wahler" <mk******@mkwah ler.net> wrote in message
news:s9******** *********@newsr ead3.news.pas.e arthlink.net...

try {
cout << *(iter + 5) << endl; // 0

Also note that you can use the possibly more intiutive
array notation with a vector:

iter[n]; /* but still no bounds checking */
-Mike

[John Harrison]

"Mike Austin" <mi**@mike-austin.com> wrote in message
news:0L******** *************@b gtnsc04-news.ops.worldn et.att.net...

Hi all. Just working on a small virtual machine, and thought about using
vector iterators instead of pointer arithmetic. Question is, why does an
iterator plus any number out of range not generate a out_of_range
exception?
Maybe this is a gcc issue?

Vector iterators are often implemented as pointers, i.e. something like

template <class T>
class vector
{
public:
typedef T* iterator;
typedef const T* const_iterator;

So vector iterators don't throw exceptions for the same reasons that
ordinary pointers don't.

john

[Ron Natalie]

Mike Austin wrote:

Hi all. Just working on a small virtual machine, and thought about using
vector iterators instead of pointer arithmetic. Question is, why does an
iterator plus any number out of range not generate a out_of_range exception?
It's never required to. It's undefined behavior to cause an iterator
to go outside the bounds of the array (with the exception of one past the
end).

cout << *(iter + 5) << endl; // 0
Evaluating expression (iter + 5) is undefined beahvior.
cout << code.at( 10 ) << endl; // vector [] access out of range

This is OK. At specifically throws an exception for out of range.

[Mike Wahler]

"John Harrison" <jo************ *@hotmail.com> wrote in message
news:2t******** *****@uni-berlin.de...

"Mike Austin" <mi**@mike-austin.com> wrote in message
news:0L******** *************@b gtnsc04-news.ops.worldn et.att.net...

Hi all. Just working on a small virtual machine, and thought about using vector iterators instead of pointer arithmetic. Question is, why does an iterator plus any number out of range not generate a out_of_range
exception?
Maybe this is a gcc issue?

Vector iterators are often implemented as pointers, i.e. something like

template <class T>
class vector
{
public:
typedef T* iterator;
typedef const T* const_iterator;

So vector iterators don't throw exceptions for the same reasons that
ordinary pointers don't.

That's possibly an 'incidental' reason for some implementations ,
but imo not "the" reason, which is to allow best possible performance
by not imposing bounds-check overhead.

-Mike

[Adrian]

Mike Austin wrote:

Hi all. Just working on a small virtual machine, and thought about using
vector iterators instead of pointer arithmetic. Question is, why does an
iterator plus any number out of range not generate a out_of_range exception?
Maybe this is a gcc issue?

I'm using gcc version 3.3.3 (cygwin special).

Here's the full sample code:

#include <iostream>
#include <vector>
#include <stdexcept>
using namespace std;

int main() {
vector<int> code;
code.push_back( 10L );
code.push_back( 20L );

vector<int>::it erator iter = code.begin();
try {
cout << *(iter + 5) << endl; // 0
cout << code.at( 10 ) << endl; // vector [] access out of range
} catch( out_of_range e ) {
cout << e.what() << endl;
}

return 0;
}

May well be wrong, but I belive only the member function at() will throw
an out_of_range, so you need to use that to test, otherwise the compiler
has not idea what you are doing.

Adrian

[Mike Austin]

"Mike Austin" <mi**@mike-austin.com> wrote in message
news:0L******** *************@b gtnsc04-news.ops.worldn et.att.net...

Hi all. Just working on a small virtual machine, and thought about using
vector iterators instead of pointer arithmetic. Question is, why does an
iterator plus any number out of range not generate a out_of_range exception? Maybe this is a gcc issue?
Thanks for everyone's reply. The reason I ask is that I want to point to a
index into vector, then read an offset by that. I could use code.at( ip +
offset ), but I wanted to do everything with iterators. I realize [] does
no bounds checking, but did not know that (iter + n) does not either.

"iter + 0" is the selector
"iter + 1" is the first argument
etc.

Thanks,
Mike
I'm using gcc version 3.3.3 (cygwin special).

Here's the full sample code:

#include <iostream>
#include <vector>
#include <stdexcept>
using namespace std;

int main() {
vector<int> code;
code.push_back( 10L );
code.push_back( 20L );

vector<int>::it erator iter = code.begin();
try {
cout << *(iter + 5) << endl; // 0
cout << code.at( 10 ) << endl; // vector [] access out of range
} catch( out_of_range e ) {
cout << e.what() << endl;
}

return 0;
}
Thanks,
Mike

[Mike Austin]

"Mike Wahler" <mk******@mkwah ler.net> wrote in message
news:s9******** *********@newsr ead3.news.pas.e arthlink.net...

"Mike Austin" <mi**@mike-austin.com> wrote in message
news:0L******** *************@b gtnsc04-news.ops.worldn et.att.net...

Hi all. Just working on a small virtual machine, and thought about using vector iterators instead of pointer arithmetic. Question is, why does an iterator plus any number out of range not generate a out_of_range

exception?

Because that's the way the library is designed.
If you want range checking, use vector::at().
That's what it's for.

This follows the "don't pay for what you don't use"
principle of C++. ('at()' will necessarily add more
overhead which might be unacceptable for some
applications).

Well, I don't like the way it works. I use vector so I don't have to worry
(as much) about my programs going awry.
I'd be delighted if you could help me write a "safe_itera tor" class. Here's
a start:

template <typename T>
class safe_iterator : public T::iterator {
Value operator ++() {
if( *this == container->end() ) // how to access "container" ?
throw out_of_range( "*** operator vector *(): out of range" );
}
};

Regards,
Mike

[Ivan Vecerina]

"Mike Wahler" <mk******@mkwah ler.net> wrote in message
news:s9******** *********@newsr ead3.news.pas.e arthlink.net...

If you don't use the protection of 'vector::at()' you can still protect
yourself by [..snip..] comparing against 'vector::end()' , etc.

Note that it is not obvious to compare against end(), because it may
be too late to avoid Undefined Behavior (UB):
iter += 5; // if result is > vect.end(), UB happens here!
if( iter >= vect.end() ) { ... /* but it's too late */ ... };

hth -Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form