I have written a tutorial on array oriented programming. You can find it here: http://www.purplepolygon.ugtech.net/tutorials/aop.html Would anyone like to comment on this? I wrote the tutorial when I was bored, and I was just messing around with arrays, when I realised a few things. So it's all from my own brain. , Moreta

An interesting approach to the problem indeed. A valuable learning experience for the one who writes it, but I would advise others against using it. I intend no offense, but rather some clarifications, by dealing with the following details:

A simple example (Grouping)
1. When you move your character around, the common solution is not to change the coordinates of all objects in the world (which would require lots of work), but only the coordinates of objects drawn to the screen. To do this, you store the offset, and apply it each frame.
2. Usually, code does not make any assumptions about how many objects there are in the game. Object-oriented programming would make all objects derive from a "Movable" class which has a Move(x,y) function. An iterator would allow you to iterate over all objects in the game (no matter how many there are) and call their Move member function with the arguments (-1,0), by using an adapted functor (named "move" here), resulting (after a short bit of preliminary work) in the code:

std::for_each(objects.begin( ),objects.end( ),move(-1,0));

3. Also, the container for objects is usually not an array, but often a list (so you can remove objects easily when they die). Adding objects to the list is as simple as a call to:

objects.push_back(object( ));

4. Your array-based code deals badly with changes in implementation (such as changing the objects so they don't have an "x" coordinate anymore, but rather a positional matrix), and also does not allow you to remove dead objects from the array easily.

A simple example (Linking)
Good application of arrays, although some of the repetitive work you do would be easily replaced with for loops.

A simple example (Optional Inheritance)
There is no need to code the fact that something doesn't exist (such as a field, for instance): you just don't create that something. Usually, when a field is not provided, it isn't created, so it isn't displayed either. No checking is therefore necessary to determine if a field should be displayed (if it exists, it should be). Even then, the "does not exist" information can be stored as a simple pointer (NULL if it does not exist, or the value otherwise).

Thanks for the input.

Do you think that if I used different examples, than this would be a great learning experience for someone? Because with the grouping concept, wasn't it just that I used a wrong example for that method? Like using it for moving the x coord? What if I did it on something different, surely it would be valuable.

And with the optional inheritence, I understand, but again, I think I just rushed for an example. What if I were inheriting another array with usefull data, instead of zeros? What If the array was optionally inheriting two different arrays, but this time instead of one being full of zeros, it also contained inportant information, but only needed at a certain time (optionally)?

Same with the linking, wrong example? Too redundant?

I wouldn't use the acronym "AOP". It will be confused with Aspect-Oriented Programming, which is a term that's far more well known.

rofl everyone's so damn pedantic. I'm SORRY I wrote a tutorial, and Caminman, I promise I will NEVER make a car! Dear oh dear...

Now, if you don't mind, I'm going to go play Mario Gold: Toadstool Tour. I hope NONE of you tease the way I walk xD