OOP will help you organize your code, and make autonomous objects.

Ex.

class Button {
   int x,y,w,h;
   ALLEGRO_BITMAP* img;
   
   bool IsMouseOver(int msx,int msy);
   void Draw();
   
};

Even something as simple as that will help you shorten your code. And it will help get rid of hard coded values, which are hard to modify.

http://www.cplusplus.com/doc/tutorial/

Not at all.

Object-oriented is just a way of organizing things, of which there are many ways. Objects are collections of data, and that data can only be accessed by that object's methods. That way, if you know you wrote the set and get functions correctly (to plan for unsafe/erroneous inputs), you know for a fact that that object will never have corrupted data inside it.

Basically, it's just a standard way of structuring things to keep your data from being accessed in ways you never intended. Encapsulation.

Not really. But you're incorrectly using elseif, instead of a switch statement or just a bunch of if statements. Look into those.

You also want your code in modular functions. That means you put all your statements initializing allegro in say, a function called initialize_game(). You can also do one for handle_events(), game_logic(), and draw_a_frame().

Those aren't really related. you can still group data into structs, and not be OO. But Dependency Injection is usually the way to go.

Edgar, how does OOP not lead to dependency injection? The data must go somewhere no matter if it's on the stack heap or in the bss. In this aspect classes are equivalent to using structs + functions. And "global" data is fine if you hide it behind a proper functional interface. Much like Allegro does.

Well, it's true that it's better to organize data thematically, but you can do that perfectly with C structs. And with OOP and no global data, you can't avoid having a "god object" that holds the references to all long-lived data that exists in your program either directly or recursively, or a list of such objects in your main() function.

In contrast, if you let your .c files hang on to their own long lived "global" data, but put a clean function API in front of it, you get much better modularity than with such a "god object" data hierarchy. Just think of, say, OpenGL. All you get are integer handles, all the global OpenGL state is in the GPU, safely abstracted away behind a function based interface.

Also, C is excellent for encapsulation with integer handles, or if you use incomplete struct declarations. In the header player.h header you put typedef struct Player_ Player; and all getter and setter functions, like, say `Player * player_new(int id); void player_free(Player *); VEC2D player_get_position(Player *);`, etc. You only define the internals then in the player.c file. Player new might even return a pointer from a static array for extra speed over malloc(). Or why not even typedef int Player;, for even better encapsulation.

So call me a heretic. OOP isn't a silver bullet. Before the hype, the name of the game was simply "modularity", and that is by far the more important concept.

/*
They call it C++ for a reason. Hiding of the this pointer is very nice and tidy, except for the fact that no one has a clear standard for symbol mangling in C++, which is an oversight of the C++ committee I think, because it sacrifices portability.

Another major feature of C (plus plus) is inheritance and polymorphism, which is obnoxious to implement in C. I hate writing my own vtable and having to swap out members based on configuration. And why oh why would I ever want to write my own vector implementation because I have to - it's C. It was a breeze to implement N-Dimensional Arrays of any type using templates and recursion.

I feel like I am tying my ankle to my butt when I code in C. Having to hop around on one foot when I have two perfectly good feet.

It is sad though, the state of MinGW. The C++ standard is still not implemented fully. I can't even use std::thread without using MinGW-w64.

I can see why low level library implementors would use C though, for its portability. But for higher level tasks I think C++ is the way to go, and since it interfaces with C just fine you don't have to change hardly any of your code to do it. If Java wasn't entirely contained in headers and slowed down by interpreting code and if it had a better gui and layout library, I would go even further and say to use Java instead even.

To get back on topic, what have you tried so far, and what are your results? How is your understanding of classes / structs? Do you know array syntax yet and see how it can help you?

Basic C array handling with an example button class :

//*/

And since I provided an example in C I think Beoran should have to provide an example in C++. Feel my pain bro.

If you have any questions on what is posted here, ask away. Do your best to understand the code presented here though.

Attached 7zip file of source and exe , 7-zip download site

{"name":"608893","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/6\/d6e233e7ca59d3aeaa400a2ca71a9aaa.png","w":1280,"h":800,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/6\/d6e233e7ca59d3aeaa400a2ca71a9aaa"}

I'm too lazy to do proper deallocation in C these days. I figure if something went wrong enough to quit the program you have bigger problems than a memory leak that will be cleaned up by the OS anyway. </lame_excuse>

For safety it should have been this :

void free_cbutton_array(CBUTTON** cbuttonp) {
   CBUTTON* cbutton = 0;
   assert(cbuttonp);
   cbutton = *cbuttonp;
   if (cbutton) {
      free(cbutton);
   }
   *cbuttonp = 0;
}

But it looks like 'free' accepts a NULL pointer so it doesn't matter.

You're probably right. We didn't go over this, maybe someone else. But I like to handle that anyhow, to be safe.

"Never assume, it makes an ass out of you and me."

Edit: Just read the thread on "Memory Leak?", very interesting. I'll keep freeing it anyhow, but..

I thought you explained that you had an error that took up memory even after your program exited, and only running a possibly obscure Linux command would the kernel process and free it.

Edgar, we'll probably have to agree to disagree there.

Before I also used C++ a lot but I got burned repeatedly and suffered greatly because of C++ until finally I realized plain C + a nice scripting language like mruby (or lua or python if you prefer that) is a much better solution for me. Sorry for not taking you up on your offer for the buttons, I already implemented the Allegro haptics driver on windows for directx in C++ so I already did my part. Ugh!

I do agree that C needs more libraries for data structures and algorithms but I'm slowly working on solving that problem too. I'm not in favor of templates since they exchange speed for space (how much code is generated behind your back?), but with a good x-macro you can get the same effects. And I love explicit vtables like the ones Allegro uses, they give me full control, and allowed me to write a very simple wrapper driver for the windows joystick around the directx and xinput driver.

You should split your main function into multiple functions, and then name each of those function with a proper name that accurately describes what it does. Here's an example of splitting using your existing code (probably not compilable):

How would this make your life easier?

1. It makes it easier to code. If you want to load a new resource, just find the function load_resources and add the necessary code, instead of scrolling around finding the correct line to add the code inside a big main function. It may seem tolerable now, but when your code reaches thousands of lines, it's really painful. Most modern IDEs or even text editors provide the functionality to jump to a function via a drop down.

2. It makes it easier to read your code. The function's name act as a summary of what the code contained inside it does (if you keep a habit of doing so.) This is very important because you will definitely forget your code in a few weeks/months, and when that happens, it's easier to understand what the hell is going on.

3. It makes your code reusable. If you have a functionality that takes a few lines of code to achieve, and you find yourself copy-pasting that code over and over again, then it's best to put it inside a function.

There are more to it, but I'm supposed to be working right now!

My understanding of structs is not good.
I haven't even tried working with structs yet.

But my understand of classes, I would say is rather okay.
Basically my understanding is, when you create a class, you can create an object either globally (Bad) or inside a function (Better), like so:
Button bo;
And this will create an instance of the Button class called bo, which we can now use to get the result of a function inside the bo instance class.
bo.getName();
This will get the output of the getName() function inside the bo instance, not the Button class right?

I will try to study all of you peoples code, that you posted here, and I will play with it until I get a basic understand on how to create my buttons in a better not-hardcoded way

I thought it was bad to use global variables? :S