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

The Partridge Family were neither partridges nor a family. Discuss.
adabo
Posts: 154
Joined: October 27th, 2012, 3:28 am
Location: Houston, Texas

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

Post by adabo » January 26th, 2017, 6:53 pm

cyboryxmen wrote: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.

Image

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?!
Very well said. It's like somebody put together the thoughts in my mind into meaningful words lol It's nice to know that I'm not alone out here.

Do I smell a hint of condescension in the air, albinopapa? haha ok, you've explained at length your love for C++. I'm just glad to have you as a friend to teach me some of the ins and outs that I hardly would have found anywhere else.

My goal here at the Chili institute is to learn how to be a better programmer and make games. It doesn't matter what language/s I use to get there. Probably what's gonna happen is that I'll be using a mix of both C and C++. I have no strong feelings one way or the other.

My first language that got me into programming was AutoHotkey. Yeah, it's just an interpreted language, but I learned so much. I didn't know it but my style of code was a blend of procedural and functional. At times I would put a lot of effort into getting a function that could be used not only in the program I was writing, but I would build it with the mind that I might share it or use it later in other projects. Then I would have functions that were only used in a very specific places in the current code and only that program.

Now that I've learned the basics of the object oriented style, I'm looking back and seeing how handy it would have been in certain areas. I think objects are pretty darn neat. Very useful in some cases. However, I've tried using pure C++ and I just fall flat on my face. I can't wrap my head around building a class only to be used for a single object. So I'm starting to figure out how to simply code the way that suits me. Maybe one day I'll be able make sense of it, and hopefully by then I'll be a good collaborator.

@albinopapa: A little update on what I've been working on: https://github.com/adabo/KeepItSimple

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

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

Post by albinopapa » January 26th, 2017, 7:47 pm

I think there is a typo in your collision code:

Code: Select all

return 
	A.position.y > B.position.x && 
	A.position.x + A.width < B.position.x + B.width && 
	A.position.y > B.position.y && 
	A.position.y + A.height < B.position.y + B.height;
Also, perhaps even a logic error.
I think you need to have:

Code: Select all

return 
	// Right side of A is greater than left side of B
	A.position.x + A.width > B.position.x && 
	// Left side of A is less than right side of B
	A.position.x < B.position.x + B.width && 
	// Bottom of A is greater than top of B
	A.position.y + A.height > B.position.y && 
	// Top of A is less than bottom of B
	A.position.y < B.position.y + B.height;
T
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

adabo
Posts: 154
Joined: October 27th, 2012, 3:28 am
Location: Houston, Texas

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

Post by adabo » January 26th, 2017, 10:04 pm

albinopapa wrote:I think there is a typo in your collision code:

Code: Select all

return 
	A.position.y > B.position.x && 
	A.position.x + A.width < B.position.x + B.width && 
	A.position.y > B.position.y && 
	A.position.y + A.height < B.position.y + B.height;
Also, perhaps even a logic error.
I think you need to have:

Code: Select all

return 
	// Right side of A is greater than left side of B
	A.position.x + A.width > B.position.x && 
	// Left side of A is less than right side of B
	A.position.x < B.position.x + B.width && 
	// Bottom of A is greater than top of B
	A.position.y + A.height > B.position.y && 
	// Top of A is less than bottom of B
	A.position.y < B.position.y + B.height;
Ah, that typo. I think the first y should be an x lol

However I'm not seeing the error in logic. What did I do wrong?

adabo
Posts: 154
Joined: October 27th, 2012, 3:28 am
Location: Houston, Texas

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

Post by adabo » January 26th, 2017, 11:22 pm

Well I figured it out. The condition that I wrote turned out to be for checking if a box was inside another box. Which is useful if I wanted that lol I might just use this, actually.

albinopapa
Posts: 4373
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

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

Post by albinopapa » January 27th, 2017, 1:58 am

Cool, I thought you could just look over my post and see what the difference was. Yeah, the code I posted checks for overlap and as you figured out, yours checks if A is inside B.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

Post Reply