On Friday, 26 October 2012 at 21:25:22 UTC, Dmitry Olshansky
wrote:
Finally got to this:
http://d.puremagic.com/issues/show_bug.cgi?id=8349
Half way through it become obvious to me that we'll have
similar problems with memcpy and it's ilk every time somebody
optimizes bit-wise copy/move/find.
More then that I think that we lack a specific set of low-level
functions that cover all of C's mem* functionality.
(The focus is on fast primitives.)
Currently there are obvious gaps:
memset ---> cast(ubyte[]) + array ops
memcpy ---> cast(ubyte[]) + array ops (also breaks with overlap)
...so far so good...
memmove ---> ???
memchr ---> cast(ubyte[]) + std.algorithm.find is *not* good
enough
(in fact std.algorithm.find arguably could use memchr to
greatly optimize some specializations (!) )
Why don't we just use C's ones?
a) CTFE-ability, alternatively we can just hard wire all of
common libc functions into CTFE
b) more generality and/or flexibility, e.g. despite it's speed
memchr can't search for ushort or uint
c) safer, as it would operate on slices of _typed_ arrays, not
pointer + number of _bytes_
So I propose the following set of low-level tools for inclusion
into Phobos or druntime:
@system:
//bitblit, doesn't call destructors/postblits
//also can be used to forcibly move structs
void rawCopy(T)(const(T) src, T dest);
//same, but also works with overlapped memory chunks
void rawTransfer(T)(const(T) src, T dest);
//fast search, bitwise comparison only
void rawFind(T)(const(T)[] src, const(T) needle);
Well the above is a sketch. Maybe I'm digging in the wrong
direction and this stuff just needs to be somewhere among
compiler's intrinsics.
(so that it can do some magic if the size is known in advance
etc.)
These should definitely be put into the language!! but they'd
have to be
100% reliable for me to adopt them over C equivalents.
unit std.memory anyone?
