Proposal: Add memcpy and const

[MaartenMJR]

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.

[MaartenMJR]

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

[felselva]

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]

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]

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]

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)