> On Dec 25, 2017, at 12:23 PM, Daryle Walker <dary...@mac.com> wrote: > > 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.
With either Collection<UInt8> or Data, the value that index(of:) returns for the second value will be one greater than what it returns for the first value in that case, regardless of how the data is stored under the hood. Charles _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
