Programming in C...yep, trying it out.

[albinopapa]

And it's a nightmare.

How can people actually enjoy writing in C.
I miss classes.
I miss RAII.
I miss templates.
I miss function overloading.
I miss operator overloading.
I miss the 'this' pointer...and how it's automatically passed for me.
I miss type safety...it eases my mind
I miss references and const references
I miss the increment operator++ and decrement operator--
I miss namespaces

I have spent a few hours over the last 24, actually about 12 out 24 hours trying to convert the Chili Framework over to C, and with the exception of his XAudio sound implementation, I've got it done. Most of the time has been spent on the sound stuff looking up how to do multi-threading in C. Had to download pthread. The biggest problem with the sound classes is it's complex interactions with each other, I'm finding it difficult to find a good comparison.

I don't intend on developing in C, especially after this. I just wanted to see what the hub-bub was about. People say that C is better than C++ because there's too much focus on the class and the time spent on setting up these classes. To me, I seeing about the same amount of setup time having to declare structs and make the associated functions, then on top of that, passing in the struct the function is to use.

If/When I finish I will post here the project just so others can see it. I more than likely will not be cleaning up the code any. Anyway, for anyone who thinks programming in C is faster than C++, please explain. If anyone who thinks programming in C is better than C++ please explain.

Ok, I'll try finishing the Sound stuff tomorrow.

[cyboryxmen]

The love for C really just stems from the anger towards C++. The anger towards C++ stems from the hatred towards the C++ community. The hatred towards the C++ community stems from the suffering inflicted by OOP that the community pushes for.

If you want to listen to a talk on why OOP is bad, here's 2 videos that explain it pretty well:
Brian Will Object-Oriented Programming is Bad
CppCon 2014: Mike Acton "Data-Oriented Design and C++"

The gist of it is that OOP in its conception has lots of great ideas but certain aspects of it just makes it hard to work with. Encapsulation and abstraction are one of its worst aspects. Here are the general points that mostly I agree with.

Most books recommend that you start thinking from a real world perspective when starting out writing code. So to make a ninja game, you'll need to make a class called Ninja that has the function Sneak() and ThrowNinjaStar() since that is what real world ninjas do. The problem is that programs do not work in the same way as their real world counterparts. In a video game, what you'll most likely end up with is 3 classes: NinjaRender, NinjaPhysics and NinjaAI. the NinjaAI needs pathfinding and behavioural information while NinjaRender needs a mesh to render with. NinjaPhysics too needs a mesh to represent the physical model but the mesh would be extremely simplified and would have certain liberties since it does not need to be seen(plus lack of vertex normals, color or uv coordinates etc.). As a result, these 3 classes share absolutely nothing in common with each other nor the real world concept of a ninja itself. So really, trying to model your code after the real world is a fool's errand and you're better off thinking it from the perspective of how the computer is actually going to simulate it.

Secondly, programs are built on good data structure; not code. Old C programming has always been about structuring and packing your data in the most efficient way possible and transforming it into other data little to no overhead. The code you write is just a tool to enable this. OOP however demands that you think the other way around. You are encouraged to make a bunch of abstract functions with little to no regard to the actual data that it would be manipulating. In fact, you are suppose to completely disregard the data and code abstractly so that you can think from the real world perspective(again, not something you want to do). As a result, you end up with data structures that are not only unoptimised but hard to code for as they are forced into conforming to the interface you made prematurely.

Finally, encapsulation practices which makes a big part of OOP is hard to follow. The idea that OOP has regarding to this is that each object is responsible for their own state and no other object is allowed to change that. This is commonly done by making the actual variables of the class private and only allowing you to change them through functions. The problem is that this is a very rudimentary security measure and really does not fully encapsulate the object's state since other objects can still change the state of the object through its functions. When making a member function that modifies the state of the object, the encapsulation goblin whispers into your ear and says "Wait a second, are you really exposing the state of the object to other objects with that function? You can't do that! That's against encapsulation! You'll need to limit access to that function to only certain classes that need them!". Encapsulation very commonly puts you into these pointless philosophy questions

To really take encapsulation seriously, you'll need to develop a hierarchy of objects where the object at one level can access and coordinate objects at the level below it. It however can't access objects 2 levels down nor objects from a different branch entirely.



This way, only the coordinator object can affect the state of the objects it is in charge of and you would easily follow encapsulation rules this way. This is probably how Bjarne intended C++ to be used as he commonly states that he designs C++ from the perspective of a systems programmer. However, coding like this is still limiting because of the imposing limit you prematurely made for yourself. Once you realise that an object from one branch needs access to another object in another branch, you get closer and closer to saying "FUCK IT!" and break encapsulation anyway with friend declarations. After seeing how many friend declarations I made in my code, I realise that I haven't taken encapsulation seriously enough. But then I realise "Do I really need to take encapsulation seriously with how limiting it makes me?". That's where I decided to just throw it all away. Ironically, a lack of structure is better than pre-conceived structure and my code becomes more organised now that I got rid of encapsulation.

I've kinda constituted the lack of encapsulation with the use of pure functional programming philosophies. Basically, that means that everything is now const and passed by value. If you are genuinely curious on how that would be achieved, I suggest that you look into learning Haskell.

In any case, C++ is very expressive and can even be used for many philosophies other than OOP. It still remains as my prefered language despite after learning other ones because of the freedom of expression it provides. I only hope that the C++ committee would continue to strive to make the language more robust and more expressive. And by that, I mean ADD MODULES TO THE STANDARD ALREADY! IT'S FUCKING 2017 AND YOU STILL EXPECT US TO USE HEADERS?!

[albinopapa]

I have found myself many-a-time trying to figure out ways of having different classes interact and still use encapsulation, however, I still feel that encapsulation is a good thing. As discussed previously in other threads in this forum, using getters/setters can have their place. Having getters return by value is a way of allowing the object B to know about object A's data while not allowing it to change the state of A. Using setters can be useful if you have it do more than just set the new value, like making sure that the value is valid before setting the new value.

I am also currently working on a project with a friend where we through a lot of encapsulation out of the window, instead of friending though, we just made all members public...not sure why we didn't just use structs, oh well. Coding went by so much faster without the constraints of design decisions based on abstraction. The problem currently is how we can't easily find things. Since everything can be accessed from everywhere else, it's easy to just throw something in and forget where you put it.

To me, I think it is going to be easier to develop a skeleton project, get it working breaking encapsulation then refactor to use encapsulation...at least that's what I'm hoping will happen.

I don't know, I like having all my data and related functions to be right there in one place, in the class, not just in the header file or cpp file. I like being able to call a function and not have to pass so many parameters or none at all, since the 'this' pointer is implicitly passed by C++.

Anyway, thanks for the info, I believe I've seen the CppCon vid before and others stating why OOP is terrible, I just have a different outlook. I like encapsulation, even when it does frustrate me.

----------------------------------------------------------
An update on my C port of the chili framework.
Apparently, some of the new DX APIs don't really support C, like DirectWrite and Direct2D. For the moment that is what my research has come up with.

For instance, in C++ when you declare a struct Foo{}, you declare a struct Foo. In C when you declare a struct Foo{}, you aren't really declaring it. struct Foo is for forward declaration when passing to a function for instance. To declare a struct Foo{} in C, you have to declare a typedef struct Foo{} Foo. That being said, the DirectWrite interfaces don't do that, so even if it does declare the vtbl structs with all the function pointers, it doesn't work. enums too seem to need this approach of typedef declaration

typedef enum MyEnums
{
Item0, Item1
}MyEnums;

[MrGodin]

I think i'd pull my hair out without classes, although I am still trying to figure out the best way to use them.

[albinopapa]

Graphics work, sound api is a nightmare to look at and think about all the things needed to port. Mostly the callbacks and the multi-threading. Downloaded pthread files to handle multi-threading, hopefully that is pretty straight forward.

For anyone wanting to take a look:
https://github.com/albinopapa/poo_game.git

The poos and dude don't move right now, but the goal color cycles and everything else is drawn.

[MrGodin]

I think you have the wrong link there. Full on c++ code there

[albinopapa]

Switch to the ChiliFramework_Proceduarl_C branch if this link doesn't work.

[albinopapa]

Thanks for letting me know MrGodin, it was kind of late when I posted that, was ready to relax before going to bed.

[albinopapa]

Ok, pushed the fixes. The movement is working for the poo game.
No sound, but that wasn't the goal of this experiment.

All in all, this was an interesting detour. As stated in my first post, I love me some C++ and classes. The C language was so restrictive and was constantly having to find ways around the limitations of the language. Granted with the use of variadic functions and macros, quite a bit can be done to extend the languages deficit when compared to templates and function overloading, but I'm not going down that road.

Also note that I could have, in a lot of places just used the member data of the objects directly instead of going through functions because struct data is publicly accessible. I chose to go through functions with the intention of mimicking encapsulation. This can be done by using forward declarations of the structs in the headers and the real defined struct is in the source file. I ended up not going this route in the end because I lost interest and since I'm not going to be switching to C as my core language I saw no need to go that far.

The code is on GitHub, check it out, the link is posted above ( make sure you get the correct branch ). If anyone else wants to add sound be my guest, it's always fun to tinker with new things.

Ok, now I need a C++ shower to wash off all that dirty C code lol.

[MrGodin]

Yup, no C for me . Way too much to do