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

[Jonathan Marler]

On Wednesday, 29 May 2019 at 17:55:49 UTC, Stefanos Baziotis 
wrote:
> On Wednesday, 29 May 2019 at 17:45:59 UTC, Jonathan Marler 
> wrote:
>>> I'm not sure about that. Does it really make sense to have 
>>> such an
>>> interface in the case where you don't have libc memcpy 
>>> available?
>>
>> Sure.  Any time you have a buffer whose type isn't known at 
>> compile-time and you need to copy between them.  For example, 
>> I have an audio program that copies buffers of audio, but the 
>> format of that buffer could be an array of floats or integers 
>> depending on the format that your audio hardware and OS 
>> support.
>>
>
> So, you copy ubyte*.

It doesn't make a difference whether the final memcpy is `void*` 
or `byte*`.  The point is that it's one function, not a template, 
and you might as well use the same type that the real memcpy uses 
so you don't change the signature when you're not using libc.

>
>>
>> Well that's why you have memcpy (for those who know what 
>> they're doing) and you have other functions for safe behavior.
>>  But you don't want to instantiate a new version of memcpy for 
>> every type variation, that's why they all just forward the 
>> call to the real memcpy.
>>
>
> You want, because instantiation and inlining of specific types 
> is
> what makes D memcpy fast. And also, what I hope will make 
> better error
> messages and instrumentation. But that's yet to be seen, most 
> important
> is the performance.

You don't want to inline the memcpy implementation.  What makes 
you think that would be faster?