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?
-- GG
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
