On Jun 28, 2011, at 2:57 PM, Thomas Engelmeier wrote: > - the endian issue you'll have to deal with anyway
Yes, that was the point. You already have to go through the struct member by member and fix the endians anyway, so reading the whole thing in as one block of data won’t actually make your code look that much “cleaner." > - regarding struct alignment: > the 80ies file format had tons of of serialized struct data which usually > better end up in a struct. > Well, streamed reading has bad performance, so you'd not want to use it in > image (or movie) manipulation code. > Streamed reading just to put it back into a struct is another anti-pattern. > > The "don't" is to use binary structs for new defined protocols for transfer, > for the given reasons. I am not sure that whatever performance improvement is to be gained by doing this is worth the inherent danger in doing this. Certainly I don’t think it’s a good idea to recommend this to people who are not familiar with the issues involved. Reading/writing structs directly into and out of files seems like something that should never be done unless you are very familiar with the way the compiler works. By all means, you can read the whole header into a buffer at once to cut the fread calls down to one, but I’d still move the values into the struct member by member (and of course, you’re going to be doing this anyway, as even if you read the data directly into the struct, you’re still going to have to go through it and assign bit-swapped values to the struct — member by member). FWIW, Apple also recommends against loading structs directly into and out of raw data (here referring to NSData objects, but it’s the same principle) for the same reason — you’re essentially relying on undocumented behavior on the part of the compiler. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Archiving/Articles/codingctypes.html#//apple_ref/doc/uid/20001294-96941 And of course, we don’t even know if performance is a concern to the OP or not. This could very likely all be a case of premature optimization, especially if creating a whole NSData object for each member is acceptable to him, as in the code originally posted. 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
