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.)
--
Dmitry Olshansky
