Player class help

[drwbns]

Hello, I have a Player class that I want to be initialized with multiple derived character controller types, something that looks like so - but how do I find what controller type is being passed into the constructor so I can initialize a new one of that type?

Code: Select all

namespace Game {

	class Player {
	public:
		Player(CController * controller,){
			char* derived = typeid(*(*controller)).name();
			(derived*)mController = new derived();
		};
		~Player(){};


	protected:
		Ogre::String mName;
\
	};
}

[Mind Calamity]

The derived player classes have their own constructors, you only write the default, generic code in the base class' constructor/destructor and then handle all the other derivative-specific code in the derived class constructor and destructor.

[drwbns]

I was talking more about these lines ( not valid code) -

Code: Select all

      Player(CController * controller,){
         char* derived = typeid(*(*controller)).name();
         (derived*)mController = new derived();
      };

I want to pass in a derived controller, then create a new one of it and store it for use. Is it possible?

[Mind Calamity]

Oh, so you want different control behaviors, I get it now. Yes, you can do that, as long as your derived classes override pre-set functions that implement the player behavior.

[bstone]

I want to pass in a derived controller, then create a new one of it and store it for use. Is it possible?

You don't want to create a new one of it in the player class itself. Just pass a new one to the player class and let it save and use it when needed.

Code: Select all

Player( CController * controller )
{
    mController = controller;
    // the player owns this controller now, don't delete it in the caller
};

// somewhere in the other part of the code galaxy ...
mPlayer = new Player( new JetpackController() );

[drwbns]

Ah ok, thanks for that. Is there any negative effect of using a reinterpret cast?

[bstone]

Yeah, most of the time reinterpret_cast<> means: 1) bad design; 2) abandoned compile time type checking; 3) access violation at some later point. Don't use the run-time type information either - disable it in your compiler settings for the peace of mind and to save some memory along the way. Templates, interfaces, and virtual methods together give you everything you might need to vary behavior between various related types. They also make your code extensible almost for free if used right.

[drwbns]

Hmm, I dsisabled it and got warnings from sdktrays.h -


warning C4541: 'dynamic_cast' used on polymorphic type 'Ogre::OverlayElement' with /GR-; unpredictable behavior may result

[bstone]

Hmm, huh? I don't use sdktrays - didn't see that coming, most likely a workaround for inflexible overlays Don't fret - turn it back but never use it