Preface all types with glm to prevent naming conflicts

[TheSlugInTub]

vec2, vec3, mat4 are pretty common names.
I would like for the types to be prefaced with glm_ to prevent naming conflicts.
the functions have it so why not the types?

[manofcosine]

What are your naming conflicts? Any examples?
If you are suffering from it right now, you can use typedef.

[appybara13]

I don't believe typedef will help with naming collisions as there will still be multiple definitions of vec2.

You could try something like this:

#define vec2 glm_vec2
#include "cglm/cglm.h"
#undef vec2

[mghcoder]

I don't know of your particular case, but have you ever heard about sed?

Requiring for everyone to change definitions is not an easy pill to swallow, you probably ain't going to get much love from a request like that.

Although vec3 might be a very common type, it'll probably 99% of the cases be the same "typedef float vec3[3];"; so it's not a reasonable request (just because there is no typedef conflict).

Just consider using "sed -ri -e 's%\b((vec|mat)[234])%cglm_\1%g' $(find ./ -type f)" after a pull from the cglm repository; that way you can use any custom type prefix you want without forcing everybody to do the same thing exactly as you do.

[manofcosine]

@appybara13
Oh, I did not notice that. You considered more. Macros are better.
I thought the naming conflicts are not code-wise but eye-wise.

@mghcoder
Have never tried sed yet, sounds pretty useful.
But it reminds me that there lies an existing solution.
The cglm struct api allows users to configure prefixes/namespaces of function names.
https://cglm.readthedocs.io/en/latest/api_struct.html#configuring-the-struct-api

I guess it can be applied to type names as well since it is implemented by macros.

But this might break the original design.
https://cglm.readthedocs.io/en/latest/getting_started.html#function-design

So, not sure the configurable names can be expanded everywhere.

[mghcoder]

@manofcosine

@mghcoder Have never tried sed yet, sounds pretty useful. But it reminds me that there lies an existing solution. The cglm struct api allows users to configure prefixes/namespaces of function names. https://cglm.readthedocs.io/en/latest/api_struct.html#configuring-the-struct-api

I guess it can be applied to type names as well since it is implemented by macros.

As it is, this only applies to struct functions names, not even struct types names can have a custom prefix or suffix defined.

Defining custom macros before #include "cglm/cglm.h" and on the build system for cglm as suggested by @appybara13 could be done, but it will also affect the macro CGLM_STRUCTAPI (responsible for generating names for the STRUCT API functions), it my end up expanding the custom type name as part of the STRUCT API functions names; it probably would be required to #define CGLM_OMIT_NS_FROM_STRUCT_API for the STRUCT API to still produce proper function names, for example cglm/struct/vec3.h:

#define glms_vec3_(NAME) CGLM_STRUCTAPI(vec3, NAME) /* here the argument vec3 will also be expanded by the preprocessor if you define it */
vec3s glms_vec3_(fill)(float val);

/* Expanded Names */
vec3s glms_vec3_fill(float val);         /* this is the default */
vec3s glms_cglm_vec3_fill(float val);    /* with #define vec3 cglm_vec3 */
vec3s cglm_vec3_fill(float val);         /* with #define vec3 cglm_vec3 and #define CGLM_OMIT_NS_FROM_STRUCT_API */

Just have a look at macro CGLM_STRUCTAPI in cglm/common.h and adjust your #defines and compiler flags accordingly.

Another alternative:
Could have something like CGLM_STRUCTAPI for the raw types and basic function names, could be #define CGLM_RAWAPI(A, ...) and by default expand names to cglm_+A+__VA_ARGS__ and allow for a custom CGLM_RAW_API_NS prefix to be defined by the user. But then would have to rewrite all functions names and types names on all source files except for the STRUCT API functions names, replacing them by the new CGLM_RAWAPI macro. That's just a lot of work, could probably write a script to do it. In the end all functions names and types names would be wrapped by a macro (just like the STRUCT API), don't know if that would be acceptable, personally I don't like it, but it would keep the API backward compatible.