Alright... I have this little issue and don''t know how to solve it. It''s probably because my knowledge of the STL is quite poor, but hey. So keep in mind that I don''t really know jack s**t about STL as you read this. In my game I need to dynamically add and remove NPC units. That is why I thought it would be good to use a list template. All my units are derived from the abstract aUnit class, so I thought it would be a good idea to have a list of aUnit and use the virtual aUnit methods to control whatever kind of unit the actual list node points to. (It''s a method called Process() defined as pure virtual in the aUnit class) So, in other words my list is defined like this: list units; Now, as I load units from my level file, I wish to add new units to the list, regardless of what kind of unit it is, hoping that polymorphism will work. It goes about something like this.

// The unit

StraightEnemy enmy;

// Init x and y

enmy.SetX(sx + (i * (STRAIGHTWIDTH + SPACING)));
enmy.SetY(sy);

// Add it to the list

l.push_back(enmy);

* l is the actual list and StraightEnemy is a class derived from the aUnit class Now this doesn''t work, at all. I set some breakpoints and found out that the application never gets out of the l.push_back(enmy) statement, but just is there as if there is some kind of infinite loop going on. Although, the problem is that I don''t even know if it will work since the list is containing aUnit objects, not pointers to aUnit objects. Now, polymorphism doesn''t work that way, right? It only works with pointers, so a aUnit pointer can point to a StraightEnemy object. Although a aUnit object cannot contain StraightEnemy data, right? So, is there a way to fix this, other than using pointer arrays (which is what I am trying to avoid by using STL)? For as much as I know, the STL container classes can only contain objects and not pointers, right? ----------------------------- Final Frontier Trader

Slicing problem : If an instance of a derived type is assigned (e.g. passed by value in a function) to a variable of a base type, the parts of the derived type not present in the base type are 'sliced' off.

You should use a list of pointers. std::list<aUnit*>.

However, remember that you have to delete these pointers before destroying list elements. Using a smart pointer class solves that problem.

[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]

[edited by - Fruny on July 8, 2003 9:27:15 AM]

Ok, so you are saying that I can use a list template, or rather list > template? I thought it was impossible to use the STL containers with pointers... Whew, then this makes it a lot easier, thanks!

[edited by - biovenger on July 8, 2003 9:52:19 AM]

No, you cannot use list<auto_ptr<aUnit> >.

STL container elements must be ''CopyConstructible'' and ''Assignable''. The ownership transfer semantics of auto_ptr disallow their use in STL containers. Use boost::shared_ptr<aUnit> instead.

list<aUnit*> is fine, but doesn''t let you use STL containers as easily, because of the manual cleanup required whenever you''re removing elements.

[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]

The manual cleanup issue is quite a small problem if you concider the way I was going to do it before; pointers-to-pointers. So, it''s a lot easier managing the destruction of objects instead of going back to the pain.

As for the boost library, I''m trying to keep the project as library-independent as can be, so I''ll see if I can handle the managing myself or create a smart pointer myself.
Thanks for all the help!

Boost is highly cross-platform, open, and generally just rocks. Highly recommended. Much of it (like the smart pointers) are just header files, like STL. Nothing to be afraid of.

quote:Original post by biovenger
The manual cleanup issue is quite a small problem if you concider the way I was going to do it before; pointers-to-pointers. So, it''s a lot easier managing the destruction of objects instead of going back to the pain.

Going to Visual Basic would almost be an improvement over pointers-to-pointers :-D *joke*

he he... you mean like storing a list of pointers in each enemy pointing to all the pointers that are pointing to it and on deletion setting them all to 0 to make sure there arent any invalid pointers left behind? *fg* would definitely work but i guess nobody wants to be trapped in pointer hell, the hell of headache.