Best interface for memcpy() (and the string.h family of functions)

[Jonathan Marler]

On Wednesday, 29 May 2019 at 18:04:07 UTC, Stefanos Baziotis 
wrote:
>> You don't want to inline the memcpy implementation.  What 
>> makes you think that would be faster?
>
> CTFE / introspection I hope and currently, benchmarks.

You didn't answer the question.  How would inlining the 
implementation of memcpy be faster? The implementation of memcpy 
doesn't need to know which types it is copying, so every call to 
it can have the exact same implementation.  You only need one 
instance of the implementation.  This means you can fine-tune it, 
many libc implementations will implement it in assembly because 
it's used so often and again, it doesn't need to know what types 
it is copying.  All it needs is 2 pointers a size.  That's why in 
D, you should only create wrappers that ensure type-safety and 
bounds checking and then forward to the real implementation, and 
those wrappers should be inlined but not the memcpy 
implementation itself.

If you want to provide you own implementation of memcpy you can, 
but inlining your implementation into every call, when the 
implementation is truly type agnostic just results in code bloat 
with no benefit.