Hello!
(Tiny intro -- I'm David Van Brink, working on game Metareal, using my own OpenGL engine, math package, everything. Pretty sure I am down with the Handmade Philosophy...)
What is the objection or downside to OOP-ish-ness for a math package?
Cheers!
(Tiny intro -- I'm David Van Brink, working on game Metareal, using my own OpenGL engine, math package, everything. Pretty sure I am down with the Handmade Philosophy...)
What is the objection or downside to OOP-ish-ness for a math package?
Cheers!
There's no reason for me to OOP this it would just add another level of abstraction onto the library that is not needed.
If you have any more questions just let me know
Thanks
- Zak
If you have any more questions just let me know
Thanks
- Zak
I'm struggling to envision what an OOP style math library would even look like. There's no data that needs to be encapsulated, I don't think any functions would be better as methods, inheritance is wholly unnecessary for vectors (if your vector3 is inheriting from vector2 then something has gone horribly wrong), and there isn't any dynamic dispatching that would call for the use of virtual methods.
Yes... I too would shun use of inheritance in this context, as unnecessary and potentially unperformant. (Vec3 extends Vec2, I agree, no thanks!)
But phrasing your data types as c++ classes gives some syntactic sugar at no (???) performance loss. Operator overloading is broadly reviled, of course, but even its most vigorous opponents sometimes condone its use when it aligns with mathematical notation. So,
and so on.
This is certainly a matter of taste. I personally prefer the latter of each, but the former is just as good. Taste is a 100% valid motivation for a design choice.
Are there issues beyond taste at play? (This is my actual & serious question, am I missing out on cycles with my approach?)
For amusement purposes only, my own are at
http://hexaflexagon.com/src/Metareal/MeLib/Source/MeMatrix.cpp
http://hexaflexagon.com/src/Metareal/MeLib/Source/MeQuat.cpp
http://hexaflexagon.com/src/Metareal/MeLib/Test/MeMatrixTests.cpp
http://hexaflexagon.com/src/Metareal/MeLib/Test/MeQuaternionsTest.cpp
But phrasing your data types as c++ classes gives some syntactic sugar at no (???) performance loss. Operator overloading is broadly reviled, of course, but even its most vigorous opponents sometimes condone its use when it aligns with mathematical notation. So,
1 2 3 | addVec3(a, b) vs a+b scaleVec3(x, a) vs x * a lengthVec3(a) vs a.length() |
and so on.
This is certainly a matter of taste. I personally prefer the latter of each, but the former is just as good. Taste is a 100% valid motivation for a design choice.
Are there issues beyond taste at play? (This is my actual & serious question, am I missing out on cycles with my approach?)
For amusement purposes only, my own are at
http://hexaflexagon.com/src/Metareal/MeLib/Source/MeMatrix.cpp
http://hexaflexagon.com/src/Metareal/MeLib/Source/MeQuat.cpp
http://hexaflexagon.com/src/Metareal/MeLib/Test/MeMatrixTests.cpp
http://hexaflexagon.com/src/Metareal/MeLib/Test/MeQuaternionsTest.cpp
Well I am not sure that operator overloading would qualify as OOP.
But if C compliance is a goal then operator overloading means maintaining an extra C++ only wrapper, which is definitely a downside. If C compliance isn't a goal though, then I don't know of anything about operator overloading that is strictly a downside.
But if C compliance is a goal then operator overloading means maintaining an extra C++ only wrapper, which is definitely a downside. If C compliance isn't a goal though, then I don't know of anything about operator overloading that is strictly a downside.
Operator and function overloading can be turned on using a simple #define
Oh! Right on, CPPMODE has just the thing. Very elegant way to provide C and C++ support at same time.
Zak, if you want, feel free to incorporate the intrinsics mat4 multiply from mine (which I got somewhere else, cited in code). I found it made a huge performance difference. Although the way I did conditionalizing for mac/win/(nothing-else-yet) trivia was sort-of unsatisfying.
The MeQuat methods might also be of interest. Not that there's any shortage of possible sources out in the aether.
Cheers!
Zak, if you want, feel free to incorporate the intrinsics mat4 multiply from mine (which I got somewhere else, cited in code). I found it made a huge performance difference. Although the way I did conditionalizing for mac/win/(nothing-else-yet) trivia was sort-of unsatisfying.
The MeQuat methods might also be of interest. Not that there's any shortage of possible sources out in the aether.
Cheers!