Although I don't have a problem anymore, I would like an explanation regarding the following headaches I went through.

I learned something interesting today... I'll bet a lot of you C++ programmers know this already but finding it out suddenly made things easier:

Pointers to arrays of objects derived from a base class != Pointers to arrays of objects of the base class

In making my game engine, one of the things it relies on is being able to make derived classes for sprites, map tiles, etc., without having to have those classes programmed into the engine itself, which itself isn't very difficult, but the engine needs to be able to store and access those derived objects, which was the not-so-simple part, made worse for things like map tiles which are stored in 2D arrays.

In trying to make this work, I kept running into crashes, constantly. I eventually started comparing pointers and discovered that the arrays of derived-object pointers, in being converted to arrays of base-object pointers, were no longer the same as before... rather, the base-object pointers were as though the array had been made out of base objects instead of derived objects.

So when communicating derived objects to base objects, I couldn't find any way to do it at an object or array level, I had to work solely with pointers, otherwise the object data is improperly interpreted in the base class object as a result of the base class generally being smaller (for memory usage) than the derived class.

To put this in perspective, here are two pieces of code. The first one doesn't work. The one below does. From my perspective, it should seem like both should work, but only the bottom one does.

---

I should also note that both compile.

I only vaguely understand why this is as it is, so if someone could spell out a bit better why the top code block fails and the bottom one doesn't, it would be appreciated.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

This is the way in which polymorphism works, the whole system is based arround pointers and dynamic allocation.

A pointer to of object type pointer-to-base class can point to the base class, or any derived classes. i.e you need to use the new, delete keywords, or assign the pointer the address of a valid(ie. class or subclass) object.

But if you declare as an explicit object (non pointer, therefore no dynamic alloction) object is immediately tied to one in memory.

Base_Class* object;

object = new Base_Class;

... or

object = new Derived_Class;

The problem lies in this statement. in_array[z] is a B_OBJECT*, which is basically the same as a B_OBJECT[] - a one dimensional array. The problem is that the final [zz] uses pointer arithmetic only - and the arithmetic has no way to know that this is actually an array of D_OBJECTs. So, the address is calculated as follows:

start_address_of_in_array_z + zz * sizeof(B_OBJECT)

This is obviously wrong - but pointer arithmetic is based only on the type of the pointer, not the type of the actual objects within.

So, why does the second approach work? Because, unlike B_OBJECT and D_OBJECT, B_OBJECT* and D_OBJECT* are actually the same size, so the indexing operation [zz] returns the proper address regardless of the actual type being pointed to.

I know this isn't really an answer to your question, but I think that a lot of the headache and confusion you're experiencing now could be easily avoided by not employing technological terrors like the ones in your code samples there in the first place. Rethink your design and how components fit together, and hopefully the solution should become clear.

99% of times, what you actually want to put in an array / N-dimension array / STL container is a reference to something. A pointer to a BITMAP, a pointer to a B_OBJECT, etc.
-> polymorphism works
-> adding / removing / displacing items from one "cell" to another will not require creating/destroying/copying full objects, only the 4 or 8 bytes for the pointer.