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

Proposal: Add memcpy and const #36

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

MaartenMJR
Copy link
Contributor

Use memcpy (which might be faster depending on the platform being used) and use 'const' for elements not being modified in functions.

This is proof-of-concept diff, of course the function prototype in mathc.h needs to be modified as well, and it requires a rewrite of other functions as well.

Use memcpy (which might be faster depending on the platform being used) and use 'const' for elements not being modified in functions
@@ -1328,15 +1329,15 @@ mfloat_t *vec3_clamp(mfloat_t *result, mfloat_t *v0, mfloat_t *v1, mfloat_t *v2)
return result;
}

mfloat_t *vec3_cross(mfloat_t *result, mfloat_t *v0, mfloat_t *v1)
mfloat_t *vec3_cross(mfloat_t *result, const mfloat_t *v0, const mfloat_t *v1)
{
mfloat_t cross[VEC3_SIZE];
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this specific case the local variable cross[] is not nessary and the results can directly be written into result[]

@felselva
Copy link
Owner

Hi, sorry for the late response, I was traveling and taking care of changes in life.

Some operations mix components, such as rotation, which means a buffer is necessary for them. I decided to keep a style that is consistent across the entire library, which allows to do this without worrying:

xxx_something(xnew, x0, x1); // x0 is copied to the buffer and later the buffer is copied to xnew
xxx_something(x0, x0, x1); // But, you can do this, too. x0 is copied to the buffer and later the buffer is copied to x0

I think const is something we can adopt, I just need time to think how it's going to be done with the 3 function styles. But, adding memcpy, or anything that requires more than stdint.h, float.h or mathc.h is something I want to avoid.

@fabiopolimeni
Copy link
Contributor

fabiopolimeni commented May 1, 2019

Maybe you can provide a simple memcpy implementation, and use the one provided by the user if she/he wants.
E.g:

#if !defined(MATHC_MEMCPY)
void _mathc_memcpy( ...
#define MATHC_MEMCPY _mathc_memcpy
#endif

Then use MATHC_MEMCPY in the implementation code instead of a for loop.

@ghost
Copy link

ghost commented Feb 12, 2020

Wouldn't even embedded targets with very restricted libc's usually have memcpy available? If that is the case, what is gained by putting so much effort into avoiding it? @fabiopolimeni 's seems like an ok solution if avoiding this dependency is really necessary, but that seems like a lot of effort for something that should be available pretty much everywhere.

@fabiopolimeni
Copy link
Contributor

Wouldn't even embedded targets with very restricted libc's usually have memcpy available? If that is the case, what is gained by putting so much effort into avoiding it? @fabiopolimeni 's seems like an ok solution if avoiding this dependency is really necessary, but that seems like a lot of effort for something that should be available pretty much everywhere.

With Microsoft compiler, you can avoid the use of any CRT by just defining #pragma intrinsic(memcpy)

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

Successfully merging this pull request may close these issues.

3 participants