Re: Data, enumerateBytes: separate blocks?
Re: Data, enumerateBytes: separate blocks?
- Subject: Re: Data, enumerateBytes: separate blocks?
- From: Daryle Walker <email@hidden>
- Date: Mon, 25 Dec 2017 13:23:19 -0500
> On Dec 24, 2017, at 3: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.
Not quite.
My first versions of this idea, pre-Swift and therefore using NSData with
Objective-C, did use the direct search functions that come with the NSData API.
There seems to be a detail you missed in my sample code that explains the use
of “enumerateBytes”:
LF-only is also a searched-for separator.
That means no matter what, I must find the first CR and the first LF. Then I
compare their relative positions (and check for another CR if the spacing is
right). What happens if whichever byte value is second is gigabytes away from
the first? (Or equivalently, only one value is present and there’s gigabytes of
trailing data to fail to find the other value.) I would end up wasting the
user’s time for a second result I’d never use.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
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