On 06-Oct-2015 01:36, Brad Anderson wrote:
On Monday, 5 October 2015 at 10:06:04 UTC, Dmitry Olshansky wrote:
Just a random idea - slices have .ptr and therefor have a bunch of
advantages such as SSE optimized copy routine.
Once I wrap a slice in something (anything) it looses ALL of that.
Now for instance std.container.Array!int.Range can easily provide .ptr
property, together with .length it would allow us to use memcpy etc.
Maybe generalize to isRandomAccessRange!Range + hasRawPtr!Range, where
hasRawPtr!(Range) would test for compatible .ptr and .length.
The benefit compared to manually slicing the .ptr and using that, then
propagating the change back to the original range is that:
- it's error prone
- awkwardly replicated at each call site
So it would be much better to retain safe range interface and
encapsulate speed-hacks inside of the algorithms.
Thoughts?
Somewhat related, C++17 is going to add the concept of Contiguous
Iterators.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3884.pdf
I'm thinking it might be better to add support RawChunkedAccess for
ranges that can offer raw pointer(s) but only in bits and peices like
e.g. a typical dequeue would or more generally segmented data
structure/range.
If these two cases could be unified in some satisfactory that would be a
huge win.
--
Dmitry Olshansky
