You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
The
ps*
ands*
functions are pretty annoying to maintain, so I was thinking of using macros to change the functions that take arrays.Old (3 separated functions):
New (1 function):
Then, the type of
MATHC_VEC3
can be configured to bestruct vec3
, orstruct vec3 *
ormfloat_t *
. If the type isstruct 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 variableresult
if needed. Not pretty, but still prettier than many other libraries around.PROS:
ps*
ands*
functions are just abstraction and they call the functions that take arrays, which means they are essentially, but not necessarily significantly, slower.ps*
ands*
counterparts of the functions that take arrays.CONS:
v[0]
will become something like thisMATHC_VEC_X(v)
, and the macro will do the job to turn it tovec[0]
orv.x
orv->x
.ps*
ands*
functions will break, thus need to migrate (if they want the newer version). But, this can be quickly fixed using search & replace.The text was updated successfully, but these errors were encountered: