Was it ever considered to make vectors copy-able?

[dzita19]

Hey there,

I've been using this lib for quite some time and I'm very content with it. I think most of the stuff is pretty handy, and API is approachable. However, one thing absolutely drives me nuts. I have to create a variable for every subexpression that would otherwise be a temporary. It bloats my code and turns a 3 lines function into 20 lines monstrosity that is absolutely unreadable. All of that because vectors are typedefs around arrays. That one design choice made it impossible to return a vector from function. That's totally opposite of the modern C approach.

So ok, I put my critics to the table. I wanna know am I wrong, is there any reason why this approach is better than simply wrapping all vectors with a struct and thus making them copy-able? Maybe that small change would improve the library, and, most importantly, it wouldn't ruin the performance.

Only thing that would be endangered is the API, since the copy-friendly API would not take as much parameters per function (obviously, no need to pass a pointer to destination struct). Some functions would be straight-up useless (like all the functions for duplicating a vector or a matrix). Maybe such an API change would be the sole reason to just let the lib be, I don't know.

I would really like to hear some feedback on this.

[recp]

Hi @dzita19,

Thanks for your feedbacks, really!

cglm offers 3 maybe 4 types of APIs (https://cglm.readthedocs.io/en/latest/api.html):

1. Inline Array API: All glm_ prefixed apis. They take some params and create or modify array types.
2. Inline Struct API: All glms_ prefixed apis. This uses struct wrapper top of array type and other useful semantics by unions. This maybe what you are looking for. Functions return structs instead of array dest params. Also you can omit glms_ namespace if you want by defining CGLM_OMIT_NS_FROM_STRUCT_API see struct api options at: https://cglm.readthedocs.io/en/latest/opt.html . Array apis can be used with struct types and vice-versa which makes things compatible and easy to work with.

This will reduce temp lines as you wish, e.g.

#define CGLM_OMIT_NS_FROM_STRUCT_API
#include <cglm/struct.h>

vec4 result = vec4_add(a, vec4_mul(b, vec4_reflect(I, N))); // ...

currently apis in global namespace like glms_look(), glms_perspective()... still have namespace prefixes like glms_. CGLM_OMIT_NS_FROM_STRUCT_API can be default in the future... Also see: https://cglm.readthedocs.io/en/latest/api_struct.html

3. Call Array API: All glmc_ prefixed apis. These apis are not forced to be inline and provided via compiled library called libcglm. This required cglm to be compiled and linked. Other apis are forced to be inline
4. SIMD API: All glmm_ prefixed apis. These are SIMD apis are used in many places where possible to make things [manually] vectorized. These part may be extended over time...

#include <cglm/cglm.h>   // INLINE ARRAY 
#include <cglm/struct.h> // INLINE STRUCT 
#include <cglm/call.h>   // COMPILED ARRAY 

Hope this helps to discover some features of cglm. There may be more convenient functions to make Array API more easy to work with. Feedbacks are welcome to improve the library, make it more robust and useful.

[dzita19]

Oh great, thanks for the quick reply. I didn't know there was a struct-based API at all. From your description, the struct API will do it for me and will spare me a lot of trouble. I will try it out as soon as possible.

[recp]

the struct API will do it for me and will spare me a lot of trouble. I will try it out as soon as possible.

Nice to hear that, feel free to bring any issues, bugs or feedbacks...