JesseGuarascia wrote:I think, in all technicality, something you could do would be:
Code: Select all
Player player = (Player)(*ships.at(0));
Kind of. The idea you are trying to present would work (the code you've presented won't), but it's still neglecting the main question (making it irrelevant): how do you keep track of the ship's type data to know how to make the cast in the first place?
JesseGuarascia wrote:Code: Select all
Player player = (Player)(*ships.at(0));
First of all, you've already dereferenced the ship as a SHIP (a less specific type), so you can't cast it to a more specific type after the dereference.
It would be:
JesseGuarascia wrote:Code: Select all
Player player = *((Player *)ships.at(0));
which would still be incorrect. You are dereferencing the pointer then
copy constructing it over to player (which is on the stack). Even if you didn't mind not accessing the original, you would be incurring a performance penalty from the copy. The correct way would be to use either a reference or a pointer:
Code: Select all
Player *player = (Player *)ships[0];
player->somePlayerSpecificVariable = 100;
But even now we haven't addressed the issue at hand. Cool, we can now refer to a ship as a player. But how do we know which ships really ARE players? If you dereference a ship that has not been allocated as a player, your application is going to segfault.
You are going to need some sort of metadata containing the "actual" type that the object was instantiated as. In a language like C# or Java, this metadata is built-in, and you could safely cast it with the call of a single function. With C++, this is more complicated. You can either 1) rethink your design 2) enable RTTI or 3) create your own metadata.
It's really up to you, although I would never recommend option #2 in a statically compiled language. There is quite a bit of overhead associated with RTTI (runtime type identification), which is why it is disabled in C++ by default. If you absolutely require this kind of functionality, you should be using a higher-level language to begin with, rather than butchering the shit out of C++.
1) Rethink your design.
Is there any particular reason you MUST store all of your ships in a single vector/array/structure other than the fact that it looks cute? Can you not have a structure for each specific type of ship (and maybe even keep the "ship" vector/array for things operating on the generic type)? The chances are that since this problem arose without using RTTI in the first place, you can very well use separate structures to solve it.
2) Depending on what compiler you use, pass the -frtti flag (thus enabling RTTI and all of its terrible associated overhead).
3) Create your own metadata.
In many scenarios (specifically in polymorphic languages not supporting RTTI), it is often necessary to create your own metadata for class types. This data can essentially be an enumeration representing the specific type of ship each object is. This data allows you to SAFELY cast down to a subclass:
Code: Select all
class Ship {
public:
enum TYPE { PLAYER, ESHIP };
private:
TYPE _type;
public:
Ship(Type type): _type(type) {}
TYPE getType() const { return _type; }
};
Now each subclass implicitly registers its own type upon its construction:
Code: Select all
class Player: public Ship {
public:
Player(): Ship(Ship::PLAYER) {}
};
and
Code: Select all
class EShip: public Ship {
public:
EShip(): Ship(Ship::ESHIP) {}
};
Now when you are iterating through the generic storage device, you are able to safely check an object's type:
Code: Select all
for(unsigned int i = 0; i < ship.size(); ++i) {
switch(ship[i]->getType()) {
case Ship::PLAYER:
((Player*)ship[i])->somePlayerOnlyVariable = 10;
break;
case Ship::ESHIP:
((EShip*)ship[i])->someEShipOnlyVariable = 20;
break;
default: //you done fucked something up
}
}
The only downside is that the parent class gains a direct/semi-direct dependency on its descendent classes, as the enumerated type must be declared within the parent. This means that adding a new sub class to the Ship class requires modifying the enumeration in the parent class to accomodate. The only time that this REALLY matters is when you have client code creating subclasses in either another library or compilation unit (where you literally cannot modify the parent source).
While many OO-extremist whores turn up their nose at such a practice (for the dependency reason), I believe this is the way to go when you don't have external compilation units creating client subclasses. These same OO programmers that bitch about such practices are of a mentality generally created from working solely with higher-level JIT compiled languages such as C# and Java--where RTTI is taken for granted and the compiler babies them. In a statically compiled language you must think outside of the box to solve problems such as this (or be a bitch, enable RTTI, and basically destroy the point of using C/++ to begin with).
There are other, FAR more advanced methods of implementing the above system that WILL enable client code to dynamically register additional types (that we use in ES), but I'm sure it would be overkill for your application.
