Re: Data, enumerateBytes: separate blocks?
Re: Data, enumerateBytes: separate blocks?
- Subject: Re: Data, enumerateBytes: separate blocks?
- From: Charles Srstka <email@hidden>
- Date: Sun, 24 Dec 2017 18:18:04 -0600
> On Dec 24, 2017, at 2:51 PM, Quincey Morris
> <email@hidden> wrote:
>
> On Dec 24, 2017, at 04:45 , Charles Srstka <email@hidden
> <mailto:email@hidden>> wrote:
>>
>> you could consider making its interface take generic collections of UInt8
>
> This would not solve the *general* problem Daryle raised. He’s looking for a
> way to test the logic of some buffer-boundary-crossing code, which makes
> sense only if he has multiple buffers, which means he must be using
> “enumerateBytes”, which not supported by Collection<UInt8>. If he doesn’t use
> enumerateBytes, then he doesn’t need anything but Data anyway.
>
> However, considering what appears to be the *actual* problem (finding the
> first CR or CR-LF or CR-CR-LF separator in a byte sequence), he could use
> Data without using enumerateBytes, and still not risk copying the data to a
> contiguous buffer.
>
> This solution would use Data’s “index(of:)” to find the first CR, then a
> combination of advancing the index and subscripting to test for LF in the
> following 1 or 2 positions.
That’s basically what I was thinking (well, using Collection<UInt8>’s
index(of:) rather than just Data’s). However, if enumerateBytes legitimately
does need to be used, you could also create a protocol containing that method
and make Data and DispatchData both retroactively conform to it.
Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden