memcpy, memset, memcmp and friends in the D Runtime

[Steven Schveighoffer]

On Thu, 10 Apr 2014 16:13:31 -0400, Dmitry Olshansky  
<dmitry.olsh at gmail.com> wrote:

> 10-Apr-2014 16:22, Daniel Murphy пишет:
>> "Dmitry Olshansky"  wrote in message  
>> news:li5lfd$203s$1 at digitalmars.com...
>>> Pros:
>>>
>>> 1. No extra scuffolding for CTFE.
>>> 2. Type-safe
>>> 3. Optional (non-release, etc.) bounds-checking.
>>> 4. Less error prone interface, e.g. memset is a known source of bugs
>>> in C, even for tried and true code bases.
>>> 5. More flexible, see e.g. memchr as an example.
>>>
>>> Cons:
>>> A set of primitives to learn.
>>
>> I don't know why you'd ever use memcpy/memset when you have:
>>
>> arr[] = 0;
>
> Calls postblit/dtor etc.? What I if I need bitwise assignment? (which is  
> what memcpy is all about)
> Yes, and with CTFE please.
> See even std.algo.move and std.algo.swap...
>
>> foreach(ref v; arr)
>>     v = 0;
>
> Same but also sucks performance-wise.
> There is a reason Phobos is littered with carefully laid out special  
> cases around C-runtime stuff.

I think a simple set of functions would be sufficient. It wouldn't even be  
that complex.

core.memops

-Steve