A solution: don''t make the list the responsible entity for creating/constructing individual objects. Instead use something like:

void blacksmith() {

CSpear *ironspear = new CSpear(...);

PlayerBackPackThatIsAList.add(ironspear);

}

The add method of the list would take a CObject* for argument, since a CSpear* is also a CObject*, this works.

The problem with those generic containers is that when you get the ironspear instance out of the backpack(list), you''ll end up with a CObject* to it, and no further information. How will you figure that you took a CSpear and not some kind of CArmor out of your backpack?

There surely are elegant solutions for this, but I don''t know an ideal solution. This problem is very interesting indeed. "Quake" dealed with this by creating a single "game thing" type called "entity_t". A door in the game would be an entity as much as a player or a flying rocket or an invisible trigger. The difference is that if you wanted to know if an entity instance had some properties, you would have to inspect entity_t''s fields (wich are all the same, so the compiler takes its picky hands out of the matter) like:

someentity.health
someentity.movetype
someentity.flags (one of the bit flags was actually "is a player" or "is a monster")

One downside is that the entity_t has about 200 data fields, and most game objects use only 10% of them. For instance, the ".frags" field is used only by players to keep a track of their individual fragcounts.

I believe that making intrincated "game object" hierarchies is not a task for a C compiler (or any language''s for that matter) to handle. It''s just too dynamic and complicated.

Of course, when you let go compiler automatic typechecking, you have to implement and maintain your own typechecking. Or else players will be able to take their ironspears out of their backpacks and eat them

--
Fabio Reis Cecin
Amok Entertainment

Hey, I''m not "anonymous", it''s me over there!!! )

- Fabio

In other words, Quake implemented Real-Time Type Information (RTTI) with a large structure. I try to design so that I don''t have to use RTTI or similar schemes, but if I had no other way out, I would use the standard C++ RTTI before trying to implement my own. Maybe RTTI wasn''t stable/complete when Quake was written, but it''s there now so it should at least be evaluated as a solution.

As an answer to the original poster, fcecin has the right idea about constructing the object with its specific needs first, then adding it to a generic list. You might have to use RTTI to get information about the object when you grab it from the list, but there can be ways around it.

The best solution (IMHO) is to abstract objects to the point where the base class has functions that generically let you do anything you want with the object. These functions are virtual, so when you make a specific object, it calls the correct virtual function from just a base-class pointer. If you can make all of your objects work this way, you don''t need RTTI.

So you basically have 3 tools:
- keeping data and functions in the object class that are general to all objects (work exactly the same)
- generalizing object functions so that clients can call virtual functions and get the right behavior specified by the appropriate derived class
- using RTTI to get a pointer to the actual derived object, then operating on that.

You can use any combination of these you see fit. Good luck.

Hiya

I''m not positive that this is relevant to what he wants, but when I have a container that keeps a list of abstract objects, I normally create an enumeration with ID''s for all of the different classes that I am using.
enum
{
OBJECT_CLASS,
WEAPON_CLASS,
ARMOR_CLASS,
etc...
}

Then in the base class (CObject) I will have a classID variable. Now when I pull out a CObject from the list, I test the classID variable agains the enumerations and act on it depending on what it is.

void CPlayer::Use( int item )
{
GObject* obj = list.getItem( item );
if (!obj)
return;

int type = obj->getClassID();

switch( type )
{
case ARMOR_CLASS:
wearArmor( (CArmor*)obj );
break;

case WEAPON_CLASS:
sharpenWeapon( (CWeapon*)obj );
break;

default:
break;
};
}

This of course is a fictional class just to show what I mean. lol


Seeya
Krippy

and again, that''s a cheezy C implementation of RTTI. Every time you add, remove, or change a type, you have to go through all of your code. The best way to solve this problem is (as Sandman said) avoid it altogether.

Thanks, didn''t know that about Quake--never looked at the source myself. (Besides, I haven''t liked a FPS since the Aliens Doom 2 mod).