By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,285 Members | 2,232 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,285 IT Pros & Developers. It's quick & easy.

vector subscript out of range

P: n/a
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

May 11 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On May 11, 12:55 am, Andy <fru...@gmail.comwrote:
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?
May 11 '07 #2

P: n/a
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


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?

May 11 '07 #3

P: n/a
On 11 Maj, 07:27, Andy <fru...@gmail.comwrote:
with vector.begin and vector.end - so I wonder why this error happens.
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?

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.

--
Erik Wikström

May 11 '07 #4

P: n/a
On May 11, 1:27 am, Andy <fru...@gmail.comwrote:

[rearranged inline]
>
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?
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
with vector.begin and vector.end - so I wonder why this error happens.
Thanks a lot for any tip or hint
Andy
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.

May 11 '07 #5

P: n/a

thanks a lot I will take a deeper loop into
May 11 '07 #6

P: n/a
On May 11, 9:12 am, Salt_Peter <pj_h...@yahoo.comwrote:
On May 11, 1:27 am, Andy <fru...@gmail.comwrote:
[...]
On the Mac the error does not appear - also when I compile it in
Release mode. Everything works fine
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.)
Yes, I compiled it on Windows in Debug Mode
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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

May 11 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.