On Tue, 22 Nov 2005 02:09:20 +0000 (UTC), David L. Davis
<SpottedTiger@yahoo.com> wrote:
>Thanks Chris!
>
>I've added your function indexr() to the XArrayT template functions (http://spottedtiger.tripod.com/D_Language/D_Sourcery_XArrayT.html) for myself and others to use, and gave you credit for it in the modified section.

thanks for the credit! cheers!

Chris

kris wrote:
> John C wrote:
<snip>
>>     memcpy(dest.ptr + destOffset, src.ptr + srcOffset, count);
<snip>
> dst[dstOffset .. dstOffset+count] = src[srcOffset .. srcOffset+count];

Almost:

    size_t items = count / src[0].sizeof;
    dst[dstOffset .. dstOffset + items]
      = src[srcOffset .. srcOffset + items];

(In a real application, you'd usually calculate items from scratch rather than convert it from a byte count.)

> (note: these cannot be overlapped, and range-checks will usually be applied)

memcpy can't handle overlapped slices either.  But it's certainly an advantage that slicing does array bounds checking, and another reason to use slicing rather than memcpy.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> kris wrote:
> 
>> John C wrote:
> 
> <snip>
> 
>>>     memcpy(dest.ptr + destOffset, src.ptr + srcOffset, count);
> 
> <snip>
> 
>> dst[dstOffset .. dstOffset+count] = src[srcOffset .. srcOffset+count];
> 
> 
> Almost:
> 
>     size_t items = count / src[0].sizeof;
>     dst[dstOffset .. dstOffset + items]
>       = src[srcOffset .. srcOffset + items];


Are you saying that slicing does not account for type-widths? If so, that would surely be a bug ;-)

In article <dlvhl3$26ma$1@digitaldaemon.com>, kris says...
>
>Stewart Gordon wrote:
>> kris wrote:
>> 
>>> John C wrote:
>> 
>> <snip>
>> 
>>>>     memcpy(dest.ptr + destOffset, src.ptr + srcOffset, count);
>> 
>> <snip>
>> 
>>> dst[dstOffset .. dstOffset+count] = src[srcOffset .. srcOffset+count];
>> 
>> 
>> Almost:
>> 
>>     size_t items = count / src[0].sizeof;
>>     dst[dstOffset .. dstOffset + items]
>>       = src[srcOffset .. srcOffset + items];
>
>
>Are you saying that slicing does not account for type-widths? If so, that would surely be a bug ;-)


actualy, IRC memcpy is the one that don't account for type-widths

"kris" <fu@bar.org> wrote in message news:dlvhl3$26ma$1@digitaldaemon.com...
> Stewart Gordon wrote:
>> kris wrote:
>>
>>> John C wrote:
>>
>> <snip>
>>
>>>>     memcpy(dest.ptr + destOffset, src.ptr + srcOffset, count);
>>
>> <snip>
>>
>>> dst[dstOffset .. dstOffset+count] = src[srcOffset .. srcOffset+count];
>>
>>
>> Almost:
>>
>>     size_t items = count / src[0].sizeof;
>>     dst[dstOffset .. dstOffset + items]
>>       = src[srcOffset .. srcOffset + items];
>
>
> Are you saying that slicing does not account for type-widths? If so, that would surely be a bug ;-)

So which is it? Either seems to work, at least in the few tests I've done.

John C wrote:
> "kris" <fu@bar.org> wrote in message news:dlvhl3$26ma$1@digitaldaemon.com...
>> Stewart Gordon wrote:
>>> kris wrote:
>>>
>>>> John C wrote:
>>> <snip>
>>>
>>>>>     memcpy(dest.ptr + destOffset, src.ptr + srcOffset, count);
>>> <snip>
>>>
>>>> dst[dstOffset .. dstOffset+count] = src[srcOffset .. srcOffset+count];
>>>
>>> Almost:
>>>
>>>     size_t items = count / src[0].sizeof;
>>>     dst[dstOffset .. dstOffset + items]
>>>       = src[srcOffset .. srcOffset + items];
>>
>> Are you saying that slicing does not account for type-widths? If so, that would surely be a bug ;-)
> 
> So which is it? Either seems to work, at least in the few tests I've done. 

That's probably because you've only tried it with a type that is one byte long.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.