Downcasting with iterator

As shown in your code (*it3) gives you a 'GameObject*'.
So if you wanted to cast that pointer to a derived type, you should be able to write: static_cast(*it3) (assuming DerivedObject inherits from GameObject, and the GameObject pointer is actually pointing to a DerivedObject instance so the cast is valid)

Quote:

Original post by Hodgman As shown in your code (*it3) gives you a 'GameObject*'. So if you wanted to cast that pointer to a derived type, you should be able to write: static_cast(*it3) (assuming DerivedObject inherits from GameObject, and the GameObject pointer is actually pointing to a DerivedObject instance so the cast is valid)

Excellent! Thank you. I got it working. Just was thrown for a loop on the syntax.

But yeah, I am being careful with this static casting. :)

Why do these shots need special handling? This is a symptom of a disease in your hierarchy design. Type-switching and casting cures the symptom, but you will likely run into similar problems again unless you find the root cause.

If they *really* need special handling, perhaps you should store them (or reference them, using a shared smart pointer) in a separate container. If the type information is important, don't throw it away. Or maybe this logic would work for all projectiles, so perhaps game objects and projectiles have enough difference in how they're handled that they shouldn't be stored together. Remember, just because you could say "EnemyShot is-a GameObject", doesn't necessarily mean this is the best way to model it in your code.

Another possibility is to add another virtual function to the game object interface, which other classes implement as an empty function. This is probably not the best solution here, but again it depends heavily on what you are trying to achieve.

Quote:

Original post by rip-off Why do these shots need special handling? This is a symptom of a disease in your hierarchy design. Type-switching and casting cures the symptom, but you will likely run into similar problems again unless you find the root cause.

Okay, what basically happens is the player object updates and checks for being hit by shots. There is a var that the shots and ONLY the shots have, which would be a bool that says whether or not the bullet was grazed (i.e. comes close to your hitbox, but doesn't hit it). That gets set to true so that way a bullet can be grazed only once.

I needed to do it this way because having the player look for shots is one loop, whereas shots looking for player would have needed me to backup the iterator for the player and use that.

If you have a better suggestion, lay it on me. I'm all for good design.

I would think that it would be better to let the bullet set its own grazed flag based on information it receives from the world about collisions. That, or put shots in a separate list, and check for collisions between the lists.

You might benefit from a "master list" of all objects for updating, and then separate collision lists with specific types of objects. This gives you some flexibility in which types get collided with which, without constantly checking the runtime types of two potential collidees. But I don't know how that would work in your specific situation.

I concur, managing the shots in a separate list would probably be better. The player probably shouldn't be checking if it has been shot. Instead, the calling code should notify the player when they get hit. This way, you can keep your logic in one loop:

for shot in shots:   if collision(shot, player):       player.onShot()       shot.onHit()