MathC - a C math library for 2D and 3D programming

Started by
25 comments, last by penguinbyebye 6 years, 5 months ago
1 hour ago, 0r0d said:

Well, when you specify something as "const", as with function input parameters, you're defining your contract with the user of that function.  If you find yourself trying to modify something that's const, you either screwed up or the person who defined that API screwed up.  Getting rid of the const is not the answer because that just hides the fact that there's some lazy programming going on.  Now, it's true that if the laziness is pervasive throughout the codebase, then you will find yourself having to go around modifying a bunch of stuff... and some might be difficult because of said laziness in the coding.   So, of course, it's up to you on how to proceed.  My personal approach is to make sure the entire codebase is const-correct as I write it and the problem never arises.  It's not hard, it's just a matter of thinking about what a function/variable does when you write it, and then declare it appropriately.  If some assumption changes, then I change the API and everyone is happy.  This pays off later in better code, fewer bugs or bugs caught earlier, and less headaches.  You also give the compiler the option to generate more optimal code.  It might not in most cases, but it could in certain specific situations.

More information on const correctness:

https://isocpp.org/wiki/faq/const-correctness

I never got in a situation where const helped me to make better code. I know what i want to modify and what i dont want to modify. In 20 years of programming i never got a single case, where the compiler helped me just because i tried to modify unmutable data.

But i had million errors using someones api which are based on const-correctness, getting it to work with my code base - creating a ton of useless friction.

I see const just as a way to differentiate between input and output parameters, but nothing more. Everything else is useless friction for me.

But i dont doubt that it may catch some bugs for lazy programmers and i agree that it makes api´s more clean.

Advertisement
7 hours ago, Finalspace said:

So to get to your library:

You have no different vector types, you have just one "vec" structure which is 32 bytes long, but you have functions which operates on 2D and 3D and 4D data only. So this will waste memory when you use 2D operations only.

Really there should be a vec2, vec3 and a vec4 and even quaternion should be a seperate quaternion structure. For matrices its the same, mat2, mat3 and mat4. Access them by an array and wrap them to union makes that possible without problems.

At first, there was a vector structure for each type (2d, 3d and 4d). But, in the practice the only wasted space is for a single `float`, the W component. Z vector is still very useful for 2D rendering with OpenGL, anyway.

7 hours ago, Finalspace said:

Const or const reference has no difference for generated code vs pointers - so no difference in performance.

But it makes the documentation / api of your functions more clear, which is input and which is output.

5 hours ago, 0r0d said:

Well, when you specify something as "const", as with function input parameters, you're defining your contract with the user of that function.

As for the const, I agree that it makes more obvious what is modified and what is not for the user. But, just like @Finalspace, I've had problems with integrating libraries from other people that had const (also no optimization, which led me to remove it):

4 hours ago, Finalspace said:

But i had million errors using someones api which are based on const-correctness, getting it to work with my code base - creating a ton of useless friction.

 

8 hours ago, ferreiradaselva said:

As for the const, I agree that it makes more obvious what is modified and what is not for the user. But, just like @Finalspace, I've had problems with integrating libraries from other people that had const (also no optimization, which led me to remove it):

 

Then the problem was either that the library was using const inappropriately or you were.  Like I said, the keyword is there partly to help enforce the contract that the API defines between itself and the user.  Of course if you're combining const-correct code with code that isnt, it will cause all sorts of problems.  This is expected.  The solution is to modify the non-const-correct code to be const-correct.  From experience, when you start doing this you realize that each of those compile errors is almost certainly pointing you to some design issue with your code.  Once your code is const-correct it makes things much easier going forward.  It's easier to look at functions and be able to tell what it can or cant do with those inputs.  It helps with variables not accidentally being modified later when you actually intended them to be immutable.  And, it helps you find design/architectural issues early because the compiler tells you exactly when you're about to do something you shouldnt do.

The way I think of const-correctness is like having a clean organized house, rather than a really messy one.  Sure, you can live in a messy house for 20 years and be happy with it, thinking that you've never seen a situation where being organized would have helped you.  But, since you were never organized in the first place, you dont really know.  You've just adapted to a mess and you work around all the problems without even realizing that they're problems.  And, trying to organize at first just seems to create more problems for no real gain.  However, if you have an organized house then the benefits are apparent and you would not want to go back to a huge mess.

 

7 hours ago, 0r0d said:

Then the problem was either that the library was using const inappropriately or you were.  Like I said, the keyword is there partly to help enforce the contract that the API defines between itself and the user.  Of course if you're combining const-correct code with code that isnt, it will cause all sorts of problems.  This is expected.  The solution is to modify the non-const-correct code to be const-correct.  From experience, when you start doing this you realize that each of those compile errors is almost certainly pointing you to some design issue with your code.  Once your code is const-correct it makes things much easier going forward.  It's easier to look at functions and be able to tell what it can or cant do with those inputs.  It helps with variables not accidentally being modified later when you actually intended them to be immutable.  And, it helps you find design/architectural issues early because the compiler tells you exactly when you're about to do something you shouldnt do.

The way I think of const-correctness is like having a clean organized house, rather than a really messy one.  Sure, you can live in a messy house for 20 years and be happy with it, thinking that you've never seen a situation where being organized would have helped you.  But, since you were never organized in the first place, you dont really know.  You've just adapted to a mess and you work around all the problems without even realizing that they're problems.  And, trying to organize at first just seems to create more problems for no real gain.  However, if you have an organized house then the benefits are apparent and you would not want to go back to a huge mess.

You can write messy code with const correctness as well - but well we should not discuss this any further, since it have nothing todo with the MathC library. But like i already sayd const are useful, but its not a magic wand for finding all your bugs.

7 hours ago, 0r0d said:

 

Not again, this is get overused so much... -.-

I started using semantic versioning (currently version 0.2.0) and the library almost suffice any needs for 2D and 3D programming.

These are some examples that are in my other project (CGDFW):

OXYkJsf.gif

Switching from projection and orthographic matrices for 3D | Using rotation matrices

screenshot.png

Using orthographic matrices and rotation matrices for 2D

screenshot.png

Using bezier functions

This topic is closed to new replies.

Advertisement