vector subscript out of range

A

Andy

Hi all,

I started developing a little app on my Mac using XCode some month
ago. The app is running fine on my mac like a sharm. Now I am nearly
ready and yesterday I moved the whole source code to a Windows PC and
build it in MS VC++. Now I got a lot of "vector subscript out of
range" assertion errors and I don't know why because on my Mac it is
working without any error. What does the Mac with this problems and
what is the magic behind the errors that I get - because when I look
at the source I can't see any problems :(

mostly the problems happen at a place where I iterate through a vector
with vector.begin and vector.end - so I wonder why this error happens.

Thanks a lot for any tip or hint
Andy
 
S

Salt_Peter

Hi all,

I started developing a little app on my Mac using XCode some month
ago. The app is running fine on my mac like a sharm. Now I am nearly
ready and yesterday I moved the whole source code to a Windows PC and
build it in MS VC++. Now I got a lot of "vector subscript out of
range" assertion errors and I don't know why because on my Mac it is
working without any error. What does the Mac with this problems and
what is the magic behind the errors that I get - because when I look
at the source I can't see any problems :(

mostly the problems happen at a place where I iterate through a vector
with vector.begin and vector.end - so I wonder why this error happens.

Thanks a lot for any tip or hint
Andy

And what would you have us do? guess?
Can't you simply write a simple test program that iterates through the
vector's elements and recreates the problem? And post it? Any chance
that you compiled the program on Windows in debug mode (assuming
assertions won't trigger in release mode on that MAC?) Did you know
that vector has the at() member function that throws an exception when
'subscript' is out of range in both debug and release mode? What
version of VC++ is involved?
Why is it that these questions need be asked at all?
 
A

Andy

perhaps I am not in that detail about my question - cuz I am new to c+
+ and also new to this group.

On the Mac the error does not appear - also when I compile it in
Release mode. Everything works fine

Yes, I compiled it on Windows in Debug Mode

I will take a look at the at() member

I also use sometimes things like that instead of an iterator
(for i=0; i < vector.size(); i++) { ... }
(for i=vector.size()-1; i>0 ;i--) { ... }

I am using MS Visual C++ Express Edition on Windows XP Pro
 
?

=?iso-8859-1?q?Erik_Wikstr=F6m?=

perhaps I am not in that detail about my question - cuz I am new to c+
+ and also new to this group.

Since you are new I'll forgive you this once, but in the future please
don't top-post, see http://www.parashift.com/c++-faq-lite/how-to-post.html
for more information.
On the Mac the error does not appear - also when I compile it in
Release mode. Everything works fine

Yes, I compiled it on Windows in Debug Mode

I will take a look at the at() member

I also use sometimes things like that instead of an iterator
(for i=0; i < vector.size(); i++) { ... }
(for i=vector.size()-1; i>0 ;i--) { ... }

The last one looks fishy, are you aware of the fact that it will not
process the first element in the vector? Use reverse_iterators
instead, then you don't have to worry about at what index to start and
end.
I am using MS Visual C++ Express Edition on Windows XP Pro

The standard library in VC++ 2005 comes with checked iterators, which
performs basic checks to see if iterators are out of range but also if
the [] operator is out of range, so if you get that kind of errors you
are probably doing something wrong and can count yourself lucky that
it has been working so far on the Mac. Try to use iterators as much as
possible and at() instead of [] and you should be able to find your
problem, another way might be to run the application in debug mode and
see where it crashes.
 
S

Salt_Peter

[rearranged inline]
perhaps I am not in that detail about my question - cuz I am new to c+
+ and also new to this group.

On the Mac the error does not appear - also when I compile it in
Release mode. Everything works fine

Yes, I compiled it on Windows in Debug Mode

I will take a look at the at() member

I also use sometimes things like that instead of an iterator
(for i=0; i < vector.size(); i++) { ... }
(for i=vector.size()-1; i>0 ;i--) { ... }

This is your problem.
(for i=vector.size()-1; i>0 ;i--) { ... }
That loop does not access vector[0] so you probably modified i in the
body somehow. If i is of type unsigned int and it is set to 0 in the
body, the statement i-- does *not* result in a negative number (there
are no negative numbers in an unsigned range). Scary, isn't it?
I am using MS Visual C++ Express Edition on Windows XP Pro

Uncomment the obvious error to catch the cute exception. The
std::vector is not required to throw anything when its elements are
accessed using operator[], not unlike the primitive array. Thats why
at() is there for.

#include <iostream>
#include <vector>
#include <stdexcept>

int main()
{
std::vector< int > v( 10 );
try
{
std::cout << "indexing up through vector:" << std::endl;
for ( size_t i = 0; i < v.size(); ++i )
{
std::cout << "v[" << i;
std::cout << "] = " << v.at( i );
std::cout << std::endl;
}
std::cout << "indexing down through vector:" << std::endl;
for ( size_t i = v.size(); i > 0; --i )
{
std::cout << "v[" << i - 1;
std::cout << "] = " << v.at( i - 1 );
std::cout << std::endl;
}
// std::cout << v.at(v.size()); // throws range_error
}
catch ( const std::exception & r_e )
{
std::cout << "Error: " << r_e.what();
std::cout << std::endl;
}
}

/*
indexing up through vector:
v[0] = 0
v[1] = 0
v[2] = 0
v[3] = 0
v[4] = 0
v[5] = 0
v[6] = 0
v[7] = 0
v[8] = 0
v[9] = 0
indexing down through vector:
v[9] = 0
v[8] = 0
v[7] = 0
v[6] = 0
v[5] = 0
v[4] = 0
v[3] = 0
v[2] = 0
v[1] = 0
v[0] = 0
*/

moral of the story: use iterators instead.
 
J

James Kanze

On May 11, 1:27 am, Andy <[email protected]> wrote:

[...]
How did you compile it on the Mac? I believe that Mac uses g++;
both g++ and VC++ will core dump on a bounds error, if compiled
with the usual debugging flags. (For g++, I use "-std=c++98
-ffor-scope -fno-gnu-keywords -foperator-names -pipe -Wall -W
-Wno-sign-compare -Wno-deprecated -Wno-non-virtual-dtor
-Wpointer-arith -Wno-unused -Wno-switch -ggdb3
-D_GLIBCXX_CONCEPT_CHECKS -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC -static-libgcc". And bounds errors
definitly do cause a core dump.)

Which means? At least "/vmg /GR /EHs /D_CRT_SECURE_NO_DEPRECATE
/MTd /GS /Ge /w /D_DEBUG" are probably necessary (but some one
who is more familiar with VC++ should feel free to correct me
here).

[...]
The
std::vector is not required to throw anything when its elements are
accessed using operator[], not unlike the primitive array. Thats why
at() is there for.

You don't want an exception in case of an error; you want a core
dump. Which is what operator[] gives you, with both g++ and
VC++, at least if you compile with the right options. After
that, I'm not too sure how you procede under Windows, but under
Unix (and presumably, Mac), you can use gdb to immediately get a
stack walkback from the core; that should indicate exactly where
you've slipped up.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top