   Is there a bug here?
  So I have a memory management related bug exhibiting strange behavior when I run my program.  Based on past experience and multiple mistakes with this sort of thing I was pretty sure I had pinpointed the source and reworked the code in question, but seeing as the bug still occurs then either my understanding of the following code snippet is vastly different from what is actually happening, OR the bug is actually somewhere else...  :)Object toAdd(*vectorIterator);  //Creates a new copy of the Object stored at the Iterator's location.Object &toAdd2 = toAdd;  //Creates a reference to the object that was just createdvectorOne.push_back(toAdd);  //Adds the "item itself" to a vector    vectorTwo.push_back(toAdd2);  //Adds a reference to said item to another vectorThe only thing I'm not sure about is if there is some problem with adding a reference to a container.  I don't see why there would be but maybe there is something I'm missing in doing so...   
  You cannot put an object instance into a vector, it will always be a copy created by the copy constructor.The same applies to a reference to an object, a copy will be created.   ;  Hmmm...So if I'm understanding you correctly that actually answers a bigger design question for me as well, but let me see if I'm getting you right.Essentially the Objects in question for my purposes are monsters that can be "owned" by any of the players in the game.  I have been maintaining one vector which contains all the monsters currently in play as part of a game_management class, as well as a vector for each player containing only the monsters they currently "own".  Now, I don't NEED to have both, but found that it made things more straightforward in some cases.What I was attempting to accomplish is create a situation where if I performed an action of some sort on a Monster via the game_management class, it would be automatically reflected in the player's "copy" of said Monster.  So I take it that I cannot do this via a simple container of references?   ;  As is always true for at least slightly complex objects it is always true for your application that you should not store value variables in vectors but just pointers to objects such as MyMonsterClass*. Because the vector makes heavy usage of the copy operator it is more time consuming to copy an instance of your monster upon resizing the vector (with a push_back for example) than copying a simple pointer would be. Just make sure that only your manager is responsible for deleting the objects when you are done with them.Then each player could maintain its own small vector storing pointers to MyMonsterClass instances. Note that your manager could still hold value instances as it does now while the player stores pointers. But due to above mentioned copy operator usage its a best practice to always create custom class instances on the heap and store the corresponding pointers in a vector.   ;Quote:Original post by PlethoraSo I take it that I cannot do this via a simple container of references?Nope you have a vector of Objects that should look something like this:std::vector<Object> SomeVector;If you add any Object to the vector it will be copied and the copy will be stored in the vector. If you then change this stored copy your changes will not effect the original object.If you wanted to store a reference you would have to do something like this (WHICH IS NOT ALLOWED!!!):std::vector<Object&> SomeVector;But if you have a central vector where you store all monsters currently in game, you could use vectors of pointers (or preferably smartpointers) for every player, that point to the monsters that belong to the player that owns the vector, like this:std::vector<Object*> OwnedMonsters;If you copy a pointer, the object it was pointing to is unaffected, i.e. doesn't get copied. But you also have to consider that this is potentially dangerous, since if you remove a monster from you central vector, pointers to that objcet will still point to the memory of the object and if you still try to use that pointer, all hell will break loose on you. So you have to somehow take care that your pointers always point to valid objects. Welcome to the wonderful world of pointers.^^Edit: Ninja'd[Edited by - DraganO on June 25, 2009 2:22:49 AM];  imo, with these you will be saved from a lot of extra headache: http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/smart_ptr.htmAt first might take short time to get used to them, but smart pointers will pay back the effort.   ;Quote:As is always true for at least slightly complex objects it is always true for your application that you should not store value variables in vectors but just pointers to objects such as MyMonsterClass*.This is not always true.Quote:What I was attempting to accomplish is create a situation where if I performed an action of some sort on a Monster via the game_management class, it would be automatically reflected in the player's "copy" of said Monster. So I take it that I cannot do this via a simple container of references?As others have noted, you cannot actually have a container of references (and your example did not). In this case you would actually want a container of pointers-to-Object (or a container of smart pointers, such as Boost's shared_ptr but not the standard libraries auto_ptr).   ;Quote:Original post by jpetrieQuote:As is always true for at least slightly complex objects it is always true for your application that you should not store value variables in vectors but just pointers to objects such as MyMonsterClass*.This is not always true.Damn you got me there ... [grin]But in the beginners section I like to paint things black and white to prevent things like that to become a bad habit before people actually know why pitfalls this might come along with.;Quote:But in the beginners section I like to paint things black and white to prevent things like that to become a bad habit before people actually know why pitfalls this might come along with.Don't do that; 'black and white' can instill equally bad habits -- always using pointers in containers is just as bad a habit as never using pointers in containers. Beginners are impressionable; often the information you omit is far less dangerous than the information you provide. It would have been more appropriate for this forum for you to omit the comment entirely and just focus on how he probably needs to use pointers in this case.   