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

[Ivan Vecerina]

"Mike Austin" <mi**@mike-austin.com> wrote in message
news:34******** *************@b gtnsc04-news.ops.worldn et.att.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?

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.

So you would need to do a check such as:
if( vect.end()-iter < 2 ) { /* throw invalid position error */ }

Note that, being a random iterator, vector::iterato r supports
the following syntax, just like native pointers:
iter[pos] // equivalent to *(iter+pos), but maybe nicer...

Finally, note that some implementations of the standard library
support a debug mode where the ranges of all iterators (and
other consistency checks) are made automatically.
(STLport is one such implementation, I do not know about gcc's).
This doesn't help write portable code, but can be helpful
during debugging.

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

[Mike Wahler]

"Ivan Vecerina" <IN************ *************** **@vecerina.com > wrote in
message news:cl******** **@newshispeed. ch...

"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 */ ... };

I was simply listing possible functions to use, depending upon
context. I wasn't trying to imply that 'end()' could protect
against e.g. 'iter+5' where that is out of bounds. 'end()'
would of course apply to iterating via a loop. I did presume
the OP would actually read about these functions before using
them.

-Mike

[Mike Austin]

"Ivan Vecerina" <IN************ *************@v ecerina.com> wrote in message
news:cl******** **@newshispeed. ch...

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

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

So you would need to do a check such as:
if( vect.end()-iter < 2 ) { /* throw invalid position error */ }

Note that, being a random iterator, vector::iterato r supports
the following syntax, just like native pointers:
iter[pos] // equivalent to *(iter+pos), but maybe nicer...

Finally, note that some implementations of the standard library
support a debug mode where the ranges of all iterators (and
other consistency checks) are made automatically.
(STLport is one such implementation, I do not know about gcc's).
This doesn't help write portable code, but can be helpful
during debugging.

I would like to use exceptions, rather than put code checks around
everything. It's just cleaner and more structured.
I don't know exactly how to implement 'safe_iterator' , but the following is
a start. Would anyone like to give me a hint?

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" );
else
T::iterator::op erator ++();
}
};

Regards,
Mike

[Ivan Vecerina]

"Mike Austin" <mi**@mike-austin.com> wrote in message
news:s6******** **********@bgtn sc05-news.ops.worldn et.att.net...

"Ivan Vecerina" <IN************ *************@v ecerina.com> wrote in
message
news:cl******** **@newshispeed. ch... .....

Finally, note that some implementations of the standard library
support a debug mode where the ranges of all iterators (and
other consistency checks) are made automatically.
(STLport is one such implementation, I do not know about gcc's).
This doesn't help write portable code, but can be helpful
during debugging.

I would like to use exceptions, rather than put code checks around
everything. It's just cleaner and more structured.
I don't know exactly how to implement 'safe_iterator' , but the following
is
a start. Would anyone like to give me a hint?

template <typename T>
class safe_iterator : public T::iterator {

Derivation is unsafe here (especially once you need
to add a data member). Unfortunately you should prefer
containment (store the base iterator as a data member).
Value operator ++() {
if( *this == container->end() ) // how to access "container" ?
throw out_of_range( "operator vector ++(): out of range" );
else
T::iterator::op erator ++();
}
};

You need to store a pointer to the container within the iterator.
Then you can use it to test for valid bounds, but eventually also
for validating iterator pairs during comparisons.
For example:
template<typena me T>
bool operator ==( safe_iterator<T > const& a
, safe_iterator<T > const& b )
{
if( a.pContainer != b.pContainer ) throw( .... );
return a.base == b.base;
};
[ What you cannot reliably check for this way is whether the
iterator is being used after having been invalidated
by a call modifying the contents of the container ]

It is not a trivial task to implement a complete iterator
interface, although some libraries can help with this
(http://www.boost.org/libs/utility/op....htm#iterator).
But in the end, implementing fully checked iterators
takes some real effort, and implies that many redundant
error checks will be included in the compiled code.
The philosophy of the STL is that operations are performed
on a valid range specified by two iterators. This way you
check upfront that the range is valid/has enough elements,
and then you perform all operations without further overhead.

I do not know specifically what you are implementing, but
if fully implementing a safe iterator seems excessively
complex, maybe you can try to adapt your approach to the
problem?
Alternatively, consider writing a few non-member functions
that encapsulate the essential operations for which you need
range checking.
E.g.:
template<class Cont, class Iter>
Iter checkedOffset(C ont const& c, Iter const& p, int offset)
{
if( offset>0 && (c.end() - p)<=offset ) throw(....);
if( offset<0 && (c.begin()-p)> offset ) throw(....);
return p+offset;
}

Regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com