Re: Need localization-proof method of transporting dates.
Re: Need localization-proof method of transporting dates.
- Subject: Re: Need localization-proof method of transporting dates.
- From: Michael Ash <email@hidden>
- Date: Mon, 6 Apr 2009 12:42:26 -0400
On Mon, Apr 6, 2009 at 1:55 AM, Greg Guerin <email@hidden> wrote:
> Michael Ash wrote:
>
>> Good point. Although this has the disadvantage of temporarily using a
>> bunch of memory, roughly doubling your footprint for this data
>> structure, that's not likely to be a problem for the typical use cases
>> for this thing.
>
> I don't see why it should take extra memory.
>
> As you say, there will be a larger NSData footprint, roughly double, if a
> single NSMutableData is used to accumulate all the individual NSData's, and
> that NSMutableData is then hashed as the final step. However, I know of no
> requirement to do it that way.
>
> A secure-hash algorithm can usually be called incrementally. Each object to
> be hashed returns its NSData, and that chunk of bytes is then digested into
> the cumulative secure-hash value. Any blocking needed by the hash is
> typically done internal to the hash algorithm itself. Even if the series of
> objects represented by an NSArray or NSDictionary were evaluated using
> simple traversal, there's still only a need for one NSData from one
> primitive object at a time. And you can put an autorelease pool at any
> level of the traversal, should it seem prudent.
>
> For example, see the openssl functions SHA1_Init(), SHA1_Update(), and
> SHA1_Final(), as contrasted to the monolithic SHA1() function. This is not
> unique to SHA1, either; most digests work this way.
>
> Or am I missing something?
Just that I assumed from context that your proposed gc_canonicalData
method would be recursive like this one, providing a single chunk at
the end. You certainly could use incremental updating instead, but
you're going to need a different architecture to do it, since you need
to run the update code for each leaf of your tree.
Mike
_______________________________________________
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