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