[raymath] Add C++ constexpr support and Matrix scalar multiplication

[lamweilun]

raymath: Add C++ constexpr support and Matrix scalar multiplication

• Make RMAPI functions constexpr in C++ mode
• Add constexpr to all C++ math operators
• Add MatrixMultiplyValue() and scalar operators
• Add MatrixZeros and MatrixUnit constants

[raysan5]

@JeffM2501 please, could you review this change? I'm not a C++ expert.

[orcmid]

There are two considerations here, though they might not matter at all.

1. constexpr is very C++ version dependent. It was introduced in C++11 and has been expanded/modified up through C++23.

2. constexpr is advisory (a bit like inline). The feature is about providing compile-time evaluation of a function call when all of the values of variables are known at compile time. The complexity of the function definition is also a factor (that depends on C++ version as well). When constexpr conditions are satisfied, there is no run-time calculation at all. It is unclear to me that those conditions are satisfied in the functions of interest.

@lamweilun Do you have examples of actual use cases where constexpr actually makes a difference? Especially in code where there is any meaningful impact on runtime performance and code footprint?

This gets us a very long way from the anchoring of raylib on C89. I suspect this is better handled, if at all, in a C++ binding or supplementary header, not in raylib.h and raymath.h.

@JeffM2501 is this consistent with your understanding?

[lamweilun]

@orcmid @JeffM2501

So just based on my testing so far, it definitely needs at least C++14 to compile due to the fact that variable declaration inside a constexpr function body was only added then.

To be fair, I have not extensively tested as to how much of a performance boost it would have. This PR is also lacking certain things such as replacing math.h with cmath if I want to make full use of constexpr math functions in C++. Also it wouldnt really be useful unless the user is compiling it in C++23 where there's constexpr version of sqrt/cos/sin.

Actually the separation of the functions into a separate header sounds reasonable. I might work on that actually. And perhaps I could also add on a build define option to enable/disable the constexpr stuffs, with disabled being the default I suppose.

Perhaps we can continue discussing once I have made those changes?

EDIT: Just to add on, actually all I wanted was to add on more constants for the Quaternion type 😆, I just thought the constexpr would be a helpful addon

[orcmid]

@lamweilun @JeffM2501

Also it wouldn't really be useful unless the user is compiling it in C++23 where there's constexpr version of sqrt/cos/sin.

Other considerations here also involve the use of intrinsics, which is another tendency for improvement of the array operations and also the use of hardware-provided implementations of trig functions and some array/vector operations. This seems particularly useful for x64 builds. (I must remind myself of this for a project I'm doing using VC/C++ where intrinsics are a compiler option.)

[lamweilun]

Not sure if the changes made above in those 2 commits are desirable. Do let me know if there are issues

[JeffM2501]

I'm not a fan of these changes, it all feels messy. I don't like one header including another, and I agree requiring C++14 is not great. I'd prefer to only require C++11 since raylib uses C99.

This just feels like an inelegant solution.

I will need to ponder.

[lamweilun]

@JeffM2501 It's completely alright if the constexpr changes goes against the philosophy of the project. We can ignore that. Though I would love to at least have the Matrix changes added 🙏🏻

[JeffM2501]

I will take a pass through raymath.h