Hi,

I wanted to switch my basic side-scrolling-engine to C++, because I think it would be(maybe?) nicer and cleaner. However I wonder what would be the best OOP approach to port it?

Currently, using plain C, all the moving objects (enemies, elevators, the player, gates) are organized in a struct Object which contains a pointer "type" to a struct ObjectProto, where all info about those types of objects in general are stored.
That means struct ObjectProto describes general properties of types of objects (the velocity of movement, the collision-rectangle, the gfx to use), which are read in from a config file, whereas struct Object describes instances of those ObjectProtos.

The third structure is one called struct Logic. It contains function pointers to four functions which manage an object, along with a name. An array of preinitialized Logic structs is kept statically within the program and describes the available Logics, i.e. behaviours of objects. So each of the ObjectProtos is assigned a logic, which controls what sort of object it really is...

To show some code (shortened)

Each logic resides in its own file and provides four functions. Those are then called like this, i.e. to update an object during the main-loop:

obj->type->logic->doSomethingCallback(obj);

So, when you read so far, you see the ugly thing about it.
The code for a logic can become quite large. They need some custom variables in the Object-struct. Currently, this is accomplished with the "union ObjVars" you can see above and ... #defines.
To illustrate:

#define switchStatus (var[0].iVar)

int LogicSwitchInit(struct Object *obj)
{
    ObjSetAni(obj, ANI_STILL);
    ObjRequestVelX(obj, 0.0);
    ST(obj->flags, FLAG_DONT_FALL);
    obj->switchStatus = 0;
    return(OBJ_OK);
}
int LogicSwitchDoSomething(struct Object *obj) {...}
int LogicSwitchCollided(struct Object *obj, struct Object *col) {...}
int LogicSwitchTriggered(struct Object *obj, int value) {...}

The proper way of doing something like that in C++ would be to define a general Object class which is inherited by classes like "Elevator", "Player" etc... using virtual functions, right?
So I'd simply call obj->doSomething() and it is then decided what type of inherited class this obj is at run-time in order to pick the right function...
So I can still organize all the Objects in a linked list or whatever, regardless of their real identity of "Player" or "Elevator".

But... how to create new ones dynamically? Currently, I can create a new structure Object, assign it a type (which goes along with a logic) and add it to my list of objects.
But to ensure that the specific objects created are instances of the right class, I'd have to do something like:

class Object;
class Player : public Object;

switch (toBeCreated) {
    case TYPE_PLAYER:
        newObj = new Player;
        ....
}

Now this seems to be rather awkward. Can it be done differently?
Should I organize the data totally differently?
I'm really new to C++ and OOP in general...

Yep, yep. This is a fairly straightforward case of inheritance. Put anything that all objects should be able to do but which may be specific to a type of object into the Object class definition, as a virtual function if you intend to override it later (or as a virtual function with no implementation — virtual void func() = 0; — if providing a default makes no sense), then use public inheritance to create your different types of object, all with their own data members as necessary.

You wish for something like the following?

char *name = "OBJElevator";
Object *newObj = new objectWithClassName(name);

Or similar? I believe C++ can't do that. What you can do, if you're reading an integer from a file that tells you the type is something like:

typedef Object *(* allocatorFunction)();

Object *allocateElevator() {return new OBJElevator;}
Object *allocateTree() {return new OBJTree;}
/* etc */

allocatorFunction allocators[8] =
{
   allocateElevator, allocateTree, /* etc */
};

Object *getObject(int type) {return allocators[type]();}

Which amounts to establishing your own mapping, exactly as the switch statement would, but is arguably more maintainable.

No doubt a C++ maven will come along and shout something about STL or Boost. My personal opinion is that both should be considered things to learn in their own right, above and beyond C++, and there's probably quite a lot of value in writing a program or two with just the C++ namespacing, inheritance and templating before launching into them unless you want to take a very long break before next finishing a program.

EDIT:

No, but you often go further forwards, to C# or to Objective-C or whatever.

In some cases, you go from C to C++ to C# to Ruby, then wrap back around to C. (As will be happening to me in the coming weeks.)

That looks/sounds essentially like the factory pattern, which is a typical way of creating objects. You would probably benefit though from stepping back and reconsidering your overall program/design from an OOP perspective rather than just trying to make your current design kind-of OOP.

What exactly do you propose that he (or anyone) will gain from doing that? You're going to waste a lot of time either writing very bad C++ (C with the occaisional class thrown in) or reinvinting the wheel on all of the commonly used things that are in STL and Boost. And then once you finish your adventure in "pure" C++, you're still going to have to spend that time learning STL and Boost before anyone is going to consider you an effective C++ programmer.

Your idea of scale is seriously out of whack and you don't seem to comprehend the idea of learning as a process. You sound offended that someone might, when faced with a complicated system, decide to learn it one chunk at a time. Further or alternatively, C++ was first invented in 1983. A public implementation of STL first became available in 1994. The logical conclusion of your post is that nobody who used C++ before 1994 could possibly have accumulated any skills that were useful after 1994.

Probably you should get down to a bookshop as soon as possible. If you read my post, you'll see that I suggest "there's probably quite a lot of value in writing a program or two with just the C++ namespacing, inheritance and templating before launching into [STL and Boost]". Probably you should go through any book that teaches C++ and cross out the self test questions at the end of any chapter prior to the STL chapter, since apparently you believe that there's nothing to gain whatsoever from writing any program until you reach the end of the book.

Just use std::map and map string to that allocator function. You'll get exactly the desired behaviour. OP wants to clean up his code, after all. STL is part of C++, unlike Boost, and thus there is no reason not to use it.

Someone who is already well familiar with programming and C can probably learn to use STL containers faster than it takes to smooth out the errors in their own linked list implementation and pointers gone wrong in those two programs.

Advising someone to write a (couple of) big projects while ignoring the vital tools to do so is bizarre.

STL is as much a part of C++ as templates, classes or virtual methods, and knowing how to use it effectively is essential to being a competent C++ programmer.

Your argument makes no sense whatsoever. You're advocating that people to things the hard way (c-style strings, raw arrays, writing their own containers, etc), and then trying to claim that they should do this to make their learning easier?

1983 was 26 years ago. 1994 was 15 years ago. Because something worked, made sense or was the only option then in no way means it is the best option today. And yes, if you took someone with C++ knowledge circa 1994 and dropped them in today's environment, they would essentially be starting over from scratch.

I don't know what kind books you're reading, but most of those written within the last decade or so introduce STL within the first few chapters (generally string and vector, not to mention iostream).

Nice straw man. I'll counter by saying that I don't agree that someone who is already well familiar with programming and C can probably learn to use STL containers instantly.

All I've said is, if you're competent in C, then it can make sense not to feel you have to adopt every single feature of C++ at once. This isn't a case of starting from nothing and reimplementing things that are bundled with the compiler, it's a case of taking functioning code and seeing how it can be made more simple by moving to a superset of the language. I don't really see how it's controversial to say "don't worry about ripping everything you have out at once; start with the fundamentals".

That is probably a better idea; but the key point remains: C++ classes don't inherently know their names or supply any other means of allocating one based on throwing a constant at a factory, even with runtime type information. You need to use your own means to map from whatever form of constant you want to use to allocation. C++ is not a reflective language.

EDIT: this appeared while I was posting...

You could say that, or you could actually read my post. Speedo states that there is no benefit to knowing anything about C++ before learning STL. The sequence of events proves otherwise. The amount of time between the events and no isn't in the slightest bit relevant.

I'd be surprised if those written more than a decade ago had a great deal on STL, since it wasn't part of the standard until 1998. The first C++ book I read was printed in, I think, 1997, and covers STL extensively as of about page 300, in a section about the likely immediate future of the language.

If it makes you feel any better, I could instead suggest that Speedo restrict himself only to books with no less than two exercises prior to one that involves an STL object, since you seem to be fixated on the exact quantities.

EDIT2:
to reiterate the point above...

Given that Florian has code that works already, you're saying that ripping out everything that could be written more easily with STL functionality and subsequently not having a working program again until everything has been reimplemented is easier than doing it piece by piece?

For crying out loud, look at the things Florian is interested in — using inheritance and local namespaces to make his code neater. I'm saying "why not just learn the bits about inheritance and using local namespaces to make your code neater, then segue into the other improvements". You're saying that is a poor way to learn?

Thank you very much for your replies!!
I'll have to rethink the whole thing, I guess. So I'll have a look at std::map and see if I can understand it now. Otherwise I'll do as Thomas proposed.
BTW, I already coded an example using STL's vectors and lists in order to get familiar with those. Really great I won't have to use a lot of malloc/free anymore...

Well, to comment on learning C++ in general:
I'm entirely self-taught and have no professional background (as you have probably guessed already ) I've been reading some C++ books over the years, but never actually started coding using it. What kept me from doing so (besides the lack of "professional pressure") was mainly that learning never seemed to come to an end. Everything that was taught in the first chapters could be made even simpler and even more elegant later - at least that was my impression.
And, well, the STL-syntax with those <> kind of scared me
Another reason was maybe that I didn'thave any problem too complex that got too awkward using plain C ... unlike now.
Plus, I now want to learn QT

All in all, the biggest problem is to see everything from an OOP point of view, I think.

One shouldn't be reimplementing working code in the first place - unless it is total mess and better rewritten for future extensions.

I'm really not sure whether translating a large program to selectively use some features of C++ is a good way to learn the language. Why not do smaller exercises to learn language features, rather than struggle to write lots of bad code?

Take vector. All there is to learn to start using it:

std::vector<X> vec; //this is how you create an empty vector
//you use push_back to add items
vec.push_back(some_x);

//or you create a vector with a particular size
std::vector<X> vec(n);
//you can still add items with push_back

//this is how you find out how many items the vector contains
unsigned n = vec.size();

//otherwise accessing items is just like your plain old dynamically allocated array
cout << vec[k];

How long does that take to learn? This already gives large advantages over handling dynamic arrays yourself.

Add iterators (obtained with begin(), end() or various functions), otherwise work like pointers (except don't provide random access (+, -) for all containers).

Then why do the professionals and the people writing the books today agree with me rather than with you?

Your argument, honestly, is something of a non-sequitur. Yes, if you do somehow manage to learn all about C++ except for STL, that knowledge will benefit you in that you should be able to pick up STL faster/easier. In the real world, there is no practical reason whatsoever that people learning C++ from the ground up should learn to do things the hard way just to put off learning something that they will need to learn anyway. Not to mention that I can tell you from experience helping/tutoring people - in most cases STL methods like string or vector are much easier and more intuitive for the average new programmer to pick up than the C methods that you're advocating.

What are you even talking about?

If he wants to learn C++, he should learn C++. Learning how to hack together some "C with classes that kinda looks like OOP" code won't do him or anyone else any good. As I told him before, he'd probably be better off completely redesigning his program to use OOP from scratch, but even if he doesn't want to go that far, he should completely re-implement things in C++ rather than hacking stuff together.

If he does follow your advice...

... it's most likely to just cause him more problems. I don't know if you just lacking an understanding of C++ to see it or if you're just blinded by this anti-STL attitude you have, but taking his C code and just dropping it into classes is going to cause him a lot more work and frustration.

Using c-strings, manual arrays and so on is going to mean that he'll have to know how to properly implement copy constructors, assignment operators, etc to deal with them... and I bet you he'd be back here within a few days asking about segfaults or memory leaks in his code. OTOH, if the OP is reasonably intelligent (which we can probably assume he is given the code he's already done in C) he should be able to pick up a reasonable understanding of std::string and std::vector in maybe 20-30 minutes, and suddenly he doesn't have to deal with any of that...

I don't see how that's relevant to my point that putting words in other people's mouths is a lot easier than actually addressing their point.

I think your problem is that you're a lot smarter than most of the people around here. You keep assuming that people are working on big projects or planning major developments. I think most of the people round here flit from project to project, kick about small programs and quickly move on.

I stand by my argument that when you're already proficient in a subset of a language, it makes more sense to figure out a larger subset, then another even larger subset, and so on, rather than jumping straight from subset to entire set. I would not advocate that anybody consider their C++ knowledge complete without learning STL (especially since it's right there in the spec), I would be surprised if Boost vanished or was substantially modified in the future, but I would not agree that someone who claimed to be a good C++ coder would be misrepresenting themselves if they didn't use Boost. I appreciate that may not exactly correlate with other people's views, but I do not appreciate the other slightly ridiculous views being attributed to me.

STL is in the C++ spec. If you don't learn STL, you haven't really learnt STL. But that doesn't mean that you need to learn STL immediately, especially not when all of Florian's specific thoughts relate to things that C++ can help a lot with and which STL is nothing whatsoever to do with.

Basic C++ factory pattern. Contains very little STL (just for the map) and no Boost at all. Assumption is that Object is the base class of everything you register.

When I read such things, I can't stop from thinking that's ugly to see. Then I know it's C++.

OOP confuses me, especially stuff like inheritance. I know, in theory, what's supposed to be going on, but I have no idea how to code it.

The first thing people seem to do when learning oop is create an endless mountain of classes that use inheritance without any useful gain in abstraction whatsoever.

I've been programming for 11 years in object-oriented languages (C++, then Java, with some dabbling in others like C#). Inheritance abuse is easy. I'm still finding cases of recent code of mine that I would think is inheritance abuse and finding that over time I'm starting to use it less and less.

The point of inheritance is polymorphism. It's not to reuse code, and it's not to implement the "strategy" pattern. Those are the two most common cases I see. If you want to reuse code, you should use containership or just normal object collaboration -- you might need to rethink the design a little. If you want to use a strategy pattern, use interfaces and actual strategy objects (interfaces map to classes with pure virtual functions in C++, or for strategy objects, possibly functors).

Note that you are using strategy pattern in your Logics struct. Also, your Logics struct is really pretty close to an interface, from a Java perspective, or a pure virtual class from a C++ one.

To get back more on the original topic, Thomas has a point but so do the others. My advice is, if you are not programming for a professional purpose, take in features of C++ as you discover them and find out what each one really means, and experiment with that. Think about how that would apply to your current project, and convert it if you want (or just settle with small tools). I don't advise ignoring STL or Boost "just because" you haven't learned all of the "C++ without STL first." Just work with what interests you the most and what you are comfortable with. If you aren't comfortable with std::vector yet because you don't understand templates, for example, that's OK come back to it later after you've learned about namespaces and some about templates.

Not all of it, just the critical mass to get things going.
The first thing to learn is the bits and pieces, basic syntax, how to declare and use classes. Some very basic STL is recommended (at least the IO part and std::string).
Then, when applying these things to actual programming, the need for containers, templates and whatnot will arise all by itself, and at that point, it's definitely time to learn STL.

That's because too many books focus too much on polymorphism when explaining OOP. OOP is about a lot of things, polymorphism is just one of them. In order of importance:
1. Organize code in functional units (classes) that contain both functions and variables
2. Hide all internal parts of a class from everything else, so that it can only be used internally, and define restrictive ways of manipulating objects (encapsulation).
3. Keep the public part of a class (the interface) as implementation-neutral as possible, so that the inner workings can be modified without consequences for the rest of the codebase (interface / implementation paradigm).
4. Polymorphism, composition, abstraction and other cool consequences of 1 to 3.

Thomas is right, start small get something workable. Its easy to get lost in "doing cool things in C++" because you're "doing cool things in C++." Its better to do things because they make sense in that scenario.

Here is a quick tutorial.

Simplest example:

#include <map>
#include <cstdio>
using namespace std;

int main()
{
    map<char*, char*> data;

    data["name"] = "Dustin";

    printf("%s", data["name"]);
}

Example Run

prog.exe
Dustin

More complicated:

Example run:

prog.exe
> shoes=green
> clothes=on
> women=present
> name=Dustin
> problems=none
Hi Dustin.

Addition to above example to output contents of data:

    for(map<char*, char*>::iterator itr = data.begin(); itr != data.end() ++itr)
        printf("'%s' = %s\n", itr->first, itr->second);

Example output:

'clothes' = on
'name' = Dustin
'problems' = none
'shoes' = green
'women' = present

(Notice that they're alphabetical? Cool huh?)

Complicated example:

Example Run:

prog.exe
Enter lines (name=value) until you have specified required variables (name, color, location): name=Dustin
Enter lines (name=value) until you have specified required variables (name, color, location): shoes=on
Enter lines (name=value) until you have specified required variables (name, color, location): location=America
Enter lines (name=value) until you have specified required variables (name, color, location): color=Red, White and Blue
Hi Dustin from America, the land of the Red, White and Blue.

map<char*, char*> data;

Careful with that, though. std::map by default uses the operator < to determine ordering. You can compare pointers, but it will be meaningless if you want to find anything later.

If you absolutely feel you must use C-style strings as the key, you'll need to specify a comparison function, so that strings are compared with strcmp. This page has an example.

Another problem that might happen with using a pointer as a key is that you might be able to modify the pointer-at string at other places. This will break the ordering of the map (keys must not change) and it won't be able to find things any more.

None of this will be a problem if you use std::string as the key. It overloads suitable comparison operators, and the map makes a (deep) copy of the string, so you can't (easily) change the key from outside.

Actually, for me, it was Ruby -> C -> C++
I left Ruby when things were ¨too easy¨ for me . Also, I don´t know why it had a horrible speed

I noticed this quote on the back of the "Objective-C Pocket Reference" book that I keep on my desk today:

"Objective-C is easy to learn and has a simple elegance that is a welcome breath of fresh air after the abstruse and confusing C++."

It's the first time I've ever seen abstruse used in a sentence.

On the main topic, I do often think C++ isn't the most aesthetic language, but I think its obsession with giving you something quite high level while running as well as something written at a much lower level is the cause of that. I'm not sure I'd go as far as abstruse...

In some cases, you go from C to C++ to C#, and then you get VB all over your face.

lolol VB

I'm thinking some mixture of C# and Ruby would be optimal, but I'm not sure what the proper ratio should be, or where to make the break. I suppose for a level-based game, Ruby would be ideal for scripting the level while C# handles the number-crunching.

Shush! Around here the consensus is that 'scripting' and 'LUA' are synonyms.

(don't tell anyone, but I script in ECMAScript)

I'm sorry to hear that.

OK... Since nobody else made the connection, I guess I will...

I guess you meant VD right? Or are those interchangeable these days

Eeeeeeew.

VB == VD? They both have something to do with viruses, right?

It's right there in the OS, and 'good enough'.