Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use macro to define the type that "regular" functions use and remove ps* and s* #29

Open
felselva opened this issue Jan 29, 2019 · 1 comment

Comments

@felselva
Copy link
Owner

felselva commented Jan 29, 2019

The ps* and s* functions are pretty annoying to maintain, so I was thinking of using macros to change the functions that take arrays.

Old (3 separated functions):

mfloat *vec3_add(mfloat *result, mfloat *v0, mfloat_t *v1)
{
        /* Implementation using parameter `result` */
}

struct vec3 *vec3_add(struct vec3 *result, struct vec3 *v0, struct vec3 *v1)
{
        /* Implementation using parameter `result` and call `vec3_add()` */
}

struct vec3 svec3_add(struct vec3 v0, struct vec3 v1)
{
        /* Implementation using local variable `result` and call `vec3_add()` */
}

New (1 function):

#ifdef MATHC_FUNCTION_HAS_PARAMETER_RESULT
MATHC_VEC3 vec3_add(MATHC_VEC3 result, MATHC_VEC3 v0, MATHC_VEC3 v1)
{
#else
MATHC_VEC3 vec3_add(MATHC_VEC3 v0, MATHC_VEC3 v1)
{
        struct vec3 result;
#endif
        // Implementation using the parameter `result` or local variable `result`...
        return result;
}

Then, the type of MATHC_VEC3 can be configured to be struct vec3, or struct vec3 * or mfloat_t *. If the type is struct vec3, then the first argument will be discarded from the function. Another option is to wrap the first parameter with a macro , but the implementation would still need the #ifdef to declare the local variable result if needed. Not pretty, but still prettier than many other libraries around.

PROS:

  • Currently, ps* and s* functions are just abstraction and they call the functions that take arrays, which means they are essentially, but not necessarily significantly, slower.
  • Faster to maintain, because there will be no need to make the ps* and s* counterparts of the functions that take arrays.

CONS:

  • Internally the functions will have to be rewritten with macros. v[0] will become something like this MATHC_VEC_X(v), and the macro will do the job to turn it to vec[0] or v.x or v->x.
  • Projects using ps* and s* functions will break, thus need to migrate (if they want the newer version). But, this can be quickly fixed using search & replace.
  • Abuse of macros.
@heitaoflower
Copy link

Good idea!, now I just use you library to do my virtual texture repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants