Polymorphism question

[Impacatus]

Let's say I have two classes:
struct color

struct red:public building

I know from the tutorial that a "color" pointer can point to an instance of "red". Is there anyway I can make a red pointer point to an instance of "red" using a color pointer as a reference? I seem to get a compiler error when I try.

If not, should I just stick to using pointers of the parent classes only? Is that less efficient? I don't really understand how these things work at the lower level.

Thanks in advance.

[kempofighter]

What is the relationship between the color and red struct? I see that the red struct inherits from building. I can't understand the question without seeing some more example code.

[Disch]

er.. I don't know how "building" fit in your example. I'm assuming you meant red to be derived from color, not building. ;P

Is there anyway I can make a red pointer point to an instance of "red" using a color pointer as a reference?

This is called "downcasting" can can be done with static_cast or dynamic_cast. It is somewhat dangerous to do this frivilously, because there's no guarantee that your color pointer actually points to a 'red'. It might point to a 'blue', or to a 'green', or to any other color.

static_cast assumes that you know for a fact that the cast is legit. IE: your color* actually points to a red. If this is not the case you will have GRAVE and hard to find bugs in your program, so be very careful when using static_cast this way:

color* colorptr = ...;
red* redptr = static_cast<red*>( colorptr );

dynamic_cast does a runtime check to ensure that the color pointer in fact points to a red object. If it doesn't, the cast will fail (null pointer returned). This is a little bit more CPU intensive, but is much safer:

color* colorptr = ...;
red* redptr = dynamic_cast<red*>( colorptr );

if( !redptr )
{
  // colorptr did not point to a red
}
else
{
  // cast okay!
}

If not, should I just stick to using pointers of the parent classes only?

No

Use whatever is appropriate to the situation.

If you are writing code that is meant to work with ANY color, then use a color*. But if you are writing code that will only work with a red, then use a red*.

Believe it or not, the need for downcasting doesn't come up as often as you might think, if your class hierarchies are carefully designed.

Is that less efficient?

No, it just makes your code harder to follow and more bug prone.

[Impacatus]

er.. I don't know how "building" fit in your example. I'm assuming you meant red to be derived from color, not building. ;P

That's correct. :) I was going to use an example with buildings, but changed my mind partway through.

This is called "downcasting" can can be done with static_cast or dynamic_cast. It is somewhat dangerous to do this frivilously, because there's no guarantee that your color pointer actually points to a 'red'. It might point to a 'blue', or to a 'green', or to any other color.

static_cast assumes that you know for a fact that the cast is legit. IE: your color* actually points to a red. If this is not the case you will have GRAVE and hard to find bugs in your program, so be very careful when using static_cast this way:

Alright, thanks. I'll look for a tutorial on those.

No

Use whatever is appropriate to the situation.

If you are writing code that is meant to work with ANY color, then use a color*. But if you are writing code that will only work with a red, then use a red*.

Believe it or not, the need for downcasting doesn't come up as often as you might think, if your class hierarchies are carefully designed.

Well, I'm almost afraid to say since it might turn out that I'm doing it wrong and will have to start over, but in my current project I'm making a universal class that all others inherit from, and an array that points to all classes, primarily for ease of serialization. When the data is loaded, all the associations need to be restored from this array.

[Disch]

Well, I'm almost afraid to say since it might turn out that I'm doing it wrong and will have to start over, but in my current project I'm making a universal class that all others inherit from, and an array that points to all classes, primarily for ease of serialization.

This isn't necessarily a bad thing.

Having a "Serializer" class that all your classes inherit from isn't a bad idea. Quite the opposite, in fact.... it's actually very practical.

The "master array" thing, not so much. Or at least, if you are using this array for anything other than serialization.

Anyway it's hard to critique without knowing the full situation. But basically I would say if you find yourself downcasting a lot -- you're probably going about it the wrong way.

[Impacatus]

The idea was that when it came to saving pointers, I'd just have to record the master array index number of the class being pointed to. It seemed like the simplest solution without having to worry about cycles and joins and all that. Loading has to be done it two stages (regular variables then pointers), but the concept seems sound. I guess I'll find out if it isn't.

But yeah, I wasn't planning on using the array for anything else.

Anyways, thanks for all your help, it really answered a lot of questions.