You're trying to treat B's and C's in the same way. For that purpose, you'll want to give them a common interface. But, they already have a common interface: A's interface. So why not move sortval into A, since apparently every A needs a sortval anyway? Alternately, you could give A a virtual sortval() method, with B and C providing implementations of their own, if you need that kind of flexibility.

That, or you could create a separate Sortable interface (which, in C++, would be done by creating an abstract base class), and have both B and C implement it (derive from it).

Tell us what you are really doing. Using generic pseudo code is often counter productive when asking questions, as it hinders understanding of what is the goal.

Obviously you may want to simplify so we're not shoulder deep in your implementation details, but a good overview of the problem is essential to a good answer in cases like these.

You could either put the information about how they take turns in Unit, so you can make the right decision that way, or keep NPC's and enemies in separate lists, as well as in the main list.

Quote:Original post by guitarstar26
If I use the unit* as the array type, the problem comes when they need to "take a turn". I don't know how to determine if the current unit in array[0] is a friendly or enemy as they take turns differently.

Exactly how does their turn-taking behavior differ? As alvaro already suggested, perhaps a member variable that indicates which side a unit is on is all you need... or, as theOcelot suggested, use different lists - which can be used to look up what side a unit is on. You could also just do both.

Another thing to consider is separating unit controlling code from the unit code itself. That is, a unit may offer various move and attack functions, but enemy units will be controlled by some AI code, while player units will be controlled based on player input. In both cases, the same unit code can be used.

However, if enemy and friendly units do differ greatly, so subclassing Unit makes sense, then your Unit class could provide a virtual takeTurn() method. No matter what unit type you're actually dealing with, they all can take turns. Exactly how they take their turns is up to them - each class can have it's own implementation of takeTurn. That's called polymorphism. You may want to read up on it. :)