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

Stefanos Baziotis sdi1600105 at di.uoa.gr
Thu May 30 08:28:50 UTC 2019


On Thursday, 30 May 2019 at 01:35:05 UTC, Mike Franklin wrote:
> On Thursday, 30 May 2019 at 01:19:54 UTC, kinke wrote:
>
>> In D, there's no ugly and unsafe need to pass slices to 
>> memcpy, as a simple `dst[] = src[]` can do the job much 
>> better, boiling down to a memcpy (with 3rd param) if T is a 
>> POD (and the two slices don't overlap, have the same length 
>> etc. if bounds checks are enabled).
>
> This is an important observation.  My vision for the GSoC 
> project was targeted primarily at druntime. D memcpy would 
> rarely, if ever, be invoked directly by most users.

If we don't really target users, then that makes this:

> Apart from that, I'm still sceptical about whether we should 
> provide
> a version with size..

Not important. Because my thought was that a lot of users would
have some pointers a, b and somehow want to do: memcpy(a, b, 
for_some_size);

What I'm thinking is that yes, we decouple D from libc _on D 
Runtime_.
But in general, users may will still want that.


More information about the Digitalmars-d mailing list