std::vector - bug or feature?

[Janina Kramer]

hi ng,

i'm working on a multiplayer game for a variable number of players and on the client side, i'm using a std::vector<CPlayer> to store
informatik about the players. CPlayer is a class that contains another std::vector<CPosition>. Because one of the players is the
client itself (and the size of the vector<CPlayer> doesn't change during a game), i thought i could store a
std::vector<CPlayer>::iterator "localplayer" that points to the respective element of the vector.
The strange thing is that when i add elements to the std::vector<CPosition> (which is nothing more than a usual member of CPlayer)
the iterator "localplayer" becomes somehow invalid (in a way that the memory it points to is no longer the actual "localplayer" but
rather some random position in memory). what's wrong here? i didn't change anything about the std::vector<CPlayer> so why can't i
use the "localplayer" iterator any more? and: would it help to store a reference to the element rather than an iterator? i fixed
this problem by using an index instead of iterator, but i'm really curious about this.

thanks in advance
janina

 

[Leor Zolman]

hi ng,

i'm working on a multiplayer game for a variable number of players and on the client side, i'm using a std::vector<CPlayer> to store
informatik about the players. CPlayer is a class that contains another std::vector<CPosition>. Because one of the players is the
client itself (and the size of the vector<CPlayer> doesn't change during a game), i thought i could store a
std::vector<CPlayer>::iterator "localplayer" that points to the respective element of the vector.
The strange thing is that when i add elements to the std::vector<CPosition> (which is nothing more than a usual member of CPlayer)
the iterator "localplayer" becomes somehow invalid (in a way that the memory it points to is no longer the actual "localplayer" but
rather some random position in memory). what's wrong here? i didn't change anything about the std::vector<CPlayer> so why can't i
use the "localplayer" iterator any more? and: would it help to store a reference to the element rather than an iterator? i fixed
this problem by using an index instead of iterator, but i'm really curious about this.

Offhand, what you've described doesn't seem like it should be invalidating
that iterator all by itself. Perhaps the iterator is just getting corrupted
by some bug in your program (e.g., assignment using an out-of-bounds vector
index)?
-leor

 

[Nick Hounsome]

hi ng,

i'm working on a multiplayer game for a variable number of players and on

informatik about the players. CPlayer is a class that contains another

client itself (and the size of the vector<CPlayer> doesn't change during a

game), i thought i could store a

std::vector<CPlayer>::iterator "localplayer" that points to the respective element of the vector.
The strange thing is that when i add elements to the

the iterator "localplayer" becomes somehow invalid (in a way that the

memory it points to is no longer the actual "localplayer" but

rather some random position in memory). what's wrong here? i didn't change

use the "localplayer" iterator any more? and: would it help to store a

reference to the element rather than an iterator? i fixed

this problem by using an index instead of iterator, but i'm really curious about this.

thanks in advance
janina

I'm afraid that you must have screwed up somewhere because what you say
sounds OK and
I'm willing to bet a lot of money that there is no bug like that which you
describe in std::vector.

Are you sure that the size of the CPlayer vector doesn't change?
How do you create it and how do you add players?
The only reasonables way to do what you say are:

std::vector<CPlayer> players;
players.reserve(MAX_PLAYERS);
for up to MAX_PLAYERS
players.push_back(player);

or

std::vector<CPlayer> players(MAX_PLAYERS);
for each player
setup(players);

The latter would probably be quite ugly.

 

[Buster]

i'm working on a multiplayer game for a variable number of players and on the client side, i'm using a std::vector<CPlayer> to store
informatik about the players. CPlayer is a class that contains another std::vector<CPosition>. Because one of the players is the
client itself (and the size of the vector<CPlayer> doesn't change during a game), i thought i could store a
std::vector<CPlayer>::iterator "localplayer" that points to the respective element of the vector.
The strange thing is that when i add elements to the std::vector<CPosition> (which is nothing more than a usual member of CPlayer)
the iterator "localplayer" becomes somehow invalid (in a way that the memory it points to is no longer the actual "localplayer" but
rather some random position in memory). what's wrong here? i didn't change anything about the std::vector<CPlayer> so why can't i
use the "localplayer" iterator any more? and: would it help to store a reference to the element rather than an iterator? i fixed
this problem by using an index instead of iterator, but i'm really curious about this.

If we're guessing, I'll take a shot:

Have you passed a vector into a function by value?

In C++, function arguments are by default passed 'by value':
the argument is copied into the parameter. If the argument is
a vector, this means its elements are copied one by one.
This is very different from Java, which uses reference semantics.
In C++ if you want reference semantics you have to say so.
Here's an example.

#include <vector>

#ifdef WRONG

// By value: v will be a brand new copy of the argument.
std::vector <int>::const_iterator f (std::vector <int> v)
{
return std::find (v.begin (), v.end (), 7);
// The vector 'v' is destroyed here, so the returned
// iterator is invalid.
}

#else

// By reference: v will be a reference to the argument.
std::vector <int>::const_iterator f (std::vector <int> & v)
{
return std::find (v.begin (), v.end (), 7);
// Only the reference 'v' is destroyed. The
// vector it refers to is not affected, so
// the iterator remains valid.
}

#endif

int main ()
{
std::vector <int> u;
u.push_back (7);

if (f (u) == u.end ()) return 1;
else return 0;
}

 

[Janina Kramer]

i'm using iterators only. no index-access at all.

 

[Janina Kramer]

i'm using the players.push_back(player) method (without reserve(..) - does that matter?)
i am very sure that the size of the vector doesn't change after assigning the "localplayer" iterator. the number of players is
constant for each round because the CPlayers have isConnected() and such kind of methods, so no need to change the vector size. and
the "localplayer" iterator is assigned after the init-round stuff.

hi ng,

i'm working on a multiplayer game for a variable number of players and on

informatik about the players. CPlayer is a class that contains another

client itself (and the size of the vector<CPlayer> doesn't change during a

game), i thought i could store a

std::vector<CPlayer>::iterator "localplayer" that points to the respective element of the vector.
The strange thing is that when i add elements to the

the iterator "localplayer" becomes somehow invalid (in a way that the

memory it points to is no longer the actual "localplayer" but

rather some random position in memory). what's wrong here? i didn't change

use the "localplayer" iterator any more? and: would it help to store a

reference to the element rather than an iterator? i fixed

this problem by using an index instead of iterator, but i'm really curious about this.

thanks in advance
janina

I'm afraid that you must have screwed up somewhere because what you say
sounds OK and
I'm willing to bet a lot of money that there is no bug like that which you
describe in std::vector.

Are you sure that the size of the CPlayer vector doesn't change?
How do you create it and how do you add players?
The only reasonables way to do what you say are:

std::vector<CPlayer> players;
players.reserve(MAX_PLAYERS);
for up to MAX_PLAYERS
players.push_back(player);

or

std::vector<CPlayer> players(MAX_PLAYERS);
for each player
setup(players);

The latter would probably be quite ugly.

 

[Janina Kramer]

the vector<CPlayer> is a member of the CGame class and it is never passed to any function.

 

[Janina Kramer]

sorry, forgot to mention that i'm not a newbie. actually, i don't really think that this problem is a bug in the c++-libs (because
someone would have certainly noticed that before i did), but on the other hand i know for sure that i don't change the
vector<CPlayer> in any way after assigning the "localplayer" iterator. i debugged the project line by line and can say that the
exact place where the localplayer iterator becomes invalid is after a call to position.push_back(..) (where position is the already
mentioned CPlayer member of type vector<CPosition>).

thanks again
janina

 

[Leor Zolman]

sorry, forgot to mention that i'm not a newbie. actually, i don't really think that this problem is a bug in the c++-libs (because
someone would have certainly noticed that before i did), but on the other hand i know for sure that i don't change the
vector<CPlayer> in any way after assigning the "localplayer" iterator. i debugged the project line by line and can say that the
exact place where the localplayer iterator becomes invalid is after a call to position.push_back(..) (where position is the already
mentioned CPlayer member of type vector<CPosition>).

thanks again
janina

Since folks seem stumped, perhaps you can give us more informatik?
For starters, the compiler, version and lib you're using, the declarations
of all the data types involved, and the code where you've seen things go
haywire. No promises, but the guesswork around here tends to get much more
accurate once folks see more of those kinds of little details.
-leor

 

[Ian]

sorry, forgot to mention that i'm not a newbie. actually, i don't really think that this problem is a bug in the c++-libs (because
someone would have certainly noticed that before i did), but on the other hand i know for sure that i don't change the
vector<CPlayer> in any way after assigning the "localplayer" iterator. i debugged the project line by line and can say that the
exact place where the localplayer iterator becomes invalid is after a call to position.push_back(..) (where position is the already
mentioned CPlayer member of type vector<CPosition>).

Please don't top post!

Do you have access to an access checking tool or debugger? If so, try
it and see what happens.

If not, post some code!

Ian

 

[Janina Kramer]

Please don't top post!

Do you have access to an access checking tool or debugger? If so, try
it and see what happens.

i used the gdb was just what i wanted to say with "i debugged the project line by line".

janina

 

[Buster]

Stop trolling. If you still want help, post some code.

 

[Old Wolf]

[quoted text edited slightly for conciseness]

i thought i could store a std::vector<CPlayer>::iterator "localplayer"
that points to the respective element of the vector. The strange thing
is that when i add elements to the std::vector<CPosition> the iterator
"localplayer" becomes somehow invalid (in a way that the memory it
points to is no longer the actual "localplayer" but rather some random
position in memory). what's wrong here?

i know for sure that i don't change the vector<CPlayer> in any way after
assigning the "localplayer" iterator. i debugged the project line by line
and can say that the exact place where the localplayer iterator becomes
invalid is after a call to position.push_back(..)

std::vector is required to store all of its items in a contiguous block
of memory. If you add a new item, and the vector is already 'full'
(ie. it is using all of the memory it has allocated so far), it has to
allocate new memory. Usually this involves allocating an entire new
large block of memory, copying all the values over, and releasing
the old memory. Obviously, this is why your iterators are now pointing
to the middle of nowhere.

You could either use a std::list (which allows insertion and deletion
without invalidating iterators/pointers/references), or keep using
a std::vector but call the "reserve()" member function beforehand.
This function pre-allocates memory for as many elements as you would
like, so that as long as you make sure the actual number of elements
doesn't exceed this limit, you can safely insert and delete without
invalidating your iterators.

 

[Leor Zolman]

std::vector is required to store all of its items in a contiguous block
of memory. If you add a new item, and the vector is already 'full'
(ie. it is using all of the memory it has allocated so far), it has to
allocate new memory. Usually this involves allocating an entire new
large block of memory, copying all the values over, and releasing
the old memory. Obviously, this is why your iterators are now pointing
to the middle of nowhere.

I think in this case we've been thinking about what would happen if there
were an iterator /to the vector/ that has just grown. Different issue. But
given that the OP still hasn't seen fit to post any /code/ to help us help
him with his problem, I'm not surprised you read it that way...
-leor

 

[Janina Kramer]

On 12 Apr 2004 14:24:34 -0700, (e-mail address removed) (Old Wolf) wrote:

I think in this case we've been thinking about what would happen if there
were an iterator /to the vector/ that has just grown. Different issue. But
given that the OP still hasn't seen fit to post any /code/ to help us help
him with his problem, I'm not surprised you read it that way...
-leor

excuse me, but i really don't know what code i shall post here. the one that doesn't change the players-vector or the one that makes
the call to position.push_back(..) without influencing the players-vector in any way. both wouldn't make much sense, would it?
(might sound like a joke, but it's not)

janina

 

[Leor Zolman]

excuse me, but i really don't know what code i shall post here. the one that doesn't change the players-vector or the one that makes
the call to position.push_back(..) without influencing the players-vector in any way. both wouldn't make much sense, would it?
(might sound like a joke, but it's not)

I don't know what code you shall post either, but I suspect I know how much
additional help you shall receive if you post none at all (and that may in
fact be at least a /little/ bit a joke.)
-leor

 

[Janina Kramer]

I don't know what code you shall post either, but I suspect I know how much
additional help you shall receive if you post none at all (and that may in
fact be at least a /little/ bit a joke.)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

i'd just say you can't solve this riddle (you = this_ng) and no code in the world will ever change anything about that...

not joking
janina

 

[Leor Zolman]

i'd just say you can't solve this riddle (you = this_ng) and no code in the world will ever change anything about that...

Do you actually believe that no one here would be able to shed any light on
your problem if they were able to see some (or all) of the actual code
involved? My experience has been that, collectively, this group (along with
the others) prefers to reach resolution on questions. That resolution may
come in the form of a bug fix, a clarification on behavior, perhaps a
consensus that the behavior is unpredictable (usually accompanied with
suggestions on how to make it predictable). But making any more progress
toward such a solution in your case would seem to currently be hampered by
a lack of information.

If you think seeing the entire app would be necessary but that would make
for too long of a post, you could ZIP up the app and post it on some web
site for downloading. If you don't have a web site available to you, email
me the file and I'll be more than happy to upload it on /my/ site, then
post a link on this list. I'm really willing to help, and so is everyone
else. But I'd still suggest starting with the aforementioned key elements
of your app; it would probably take you less effort to just do that than
you've already expended to try to convince us that it wouldn't do any good.

So the first part of your concluding line above would seem to be correct,
given the info we've been given so far. But I have serious doubts about
that last part.
-leor