«

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

On May 11, 12:55 am, Andy <fru...@gmail.com> wrote:
> 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?

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?

On 11 Maj, 07:27, Andy <fru...@gmail.com> wrote:
> > > 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

On May 11, 1:27 am, Andy <fru...@gmail.com> wrote:

[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.

thanks a lot I will take a deeper loop into

On May 11, 9:12 am, Salt_Peter <pj_h...@yahoo.com> wrote:
> On May 11, 1:27 am, Andy <fru...@gmail.com> wrote:

[...]
> > 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:
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