cglm: Functions don't use const when possible

@recp The issue isn’t C++ or not C++. The issue is that read-only variables that aren’t mutated are not marked as const, which they should be. I may make a PR and do this, as it makes my own code a bit sloppy because I can’t use const.

Also I would recommend against caring about or supporting C++. Realisitically no one would use this library over GLM if you’re using C++. GLM is just a more mature, stable library. Keep your focus and energy on everything C related.

@recp Your idea for adding the GLM_ENABLE_CONST flag seems solid. It would be enormously helpful for a project I’m working on; I’m sure it would be very helpful for others as well.

FYI: C23 will fix the issues highlighted by recp

...
An array and its element type are always considered to be identically qualified*)
...

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2607.pdf

@sacereda Yes please!!! That would be a godsend.

@recp I can try to upload a PR if you want. I have something like this locally, but didn’t check all the available functions yet:

const.patch

this optional solution proposed by recp sounds good, using the struct API is incovenient to me, writing portable C99 code. The API i’m working makes heavy use const parameters, lots of discarded qualifier warnings.

For the above reason, I’d vote for closing this issue. You can’t change the array parameters without causing trouble. Which means it’d break everyone that’s currently using this API with non-const arrays and require terrible casts to make it work (or, more likely, cause people to stop using this library because it broke their code).

The struct API solves the issue of non-constness by taking everything as a value instead of by reference. The original problem of “I want const values” is resolved: use structs, make them const.

In my experience, const is a nice idea, but in the end they cause many errors like the one you ran into, where types aren’t compatible for pernicious reasons. Especially when you start dealing with arrays, pointers to pointers etc., you start fighting against the compiler a lot.

However, since there’s now a struct API that doesn’t take pointers directly, doesn’t that kinda make this requirement moot? The struct functions don’t modify their parameters anyway, they take them as values and return values. So if you want to use const, you can use the struct versions, which don’t have any issues with it:

const mat4s m1 = GLMS_MAT4_IDENTITY_INIT;
const mat4s m2 = glms_mat4_copy(m1); /* no warnings here  */

So basically, the struct API already takes its read-only parameters as values, rather than pointers, and therefore “solves” this, albeit in a different way.

Also I would recommend against caring about or supporting C++. Realisitically no one would use this library over GLM if you’re using C++. GLM is just a more mature, stable library. Keep your focus and energy on everything C related.

Fair enough.

I think we need to do something like this instead of using GLM_IN, GLM_OUT, GLM_INOUTthen:

CGLM_INLINE
void
glm_vec4_add(vec4 a, vec4 b, vec4 dest);

to

CGLM_INLINE
void
glm_vec4_add(const vec4 a, const vec4 b, vec4 dest);

I may make a PR and do this, as it makes my own code a bit sloppy because I can’t use const.

@heapseeker thank you, I may wait for you if you want to work on this?