[myUserDefaults storeThisStruct:oleStyleCStruct]?

Discussion in 'Mac Programming' started by zeppenwolf, Mar 16, 2010.

  1. zeppenwolf macrumors regular


    Nov 17, 2009
    I'm carrying an app from OS9 to Cocoa...

    Is there a way to store a C struct with NSDefaults? It seems to me kind of goofy to have to "save" every atomic element one at a time, unless I'm missing something..?

    ( I've found the Apple site very difficult to get meaningful results from. I admit it-- so far, I've been using a search engine that rhymes with "frugal", and getting much more helpful results. But on this one, I'm symied both ways... )
  2. Sydde macrumors 68020


    Aug 17, 2009
    One possibility:

    Suppose you have

    myParams *myPStruct;

    which points to your struct. You might do something like this

    [[NSData alloc] initWithBytes:myPStruct length:sizeof( myParams )];

    This will give you an NSData object that contains a copy of the struct, which you can then store using NSUserDefaults. Since the plist will typically not leave the computer it will run on, you probably do not need to worry about endian-ness if you are writing a universal.
  3. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    Endian-ness isn't the only concern. You can also get borked if a 32-bit and 64-bit version run on the same computer, and the natural packing or sizes of elements in the struct differ between the two archs. One's exposure to this really depends on the elements in the struct, and how they're declared. This is one advantage to decomposing the struct and saving primitive elements: the struct itself doesn't matter, only the values. Personally, my decision would depend on whether the program was for personal use only, or for wider distribution. If the latter, definitely go for the most portable and long-lived representation (i.e. not a struct munged into NSData).
  4. Sydde macrumors 68020


    Aug 17, 2009
    A valid point, though I suppose one could accomodate the difference by redefining any pointers as unions with long longs.

    The better approach might be to redefine the struct as an NSObject supporting the NSCoding protocol with the elements its ivars. Using @property/@synthesize/dot-syntax would somewhat minimise the need to recode (a bunch of "->" references would probably have to be changed to "."). Of course, the individual elements would still have to be encoded in order to convert the object to something that could go into a plist, but at least it would be fairly elegant. The main consideration with doing this might be the very small performance hit that the accessor methods would exact.
  5. gnasher729 macrumors P6


    Nov 25, 2005
    Good luck reading the same C struct from a 32 bit or 64 bit version of your code, or from a PowerPC version. And you will of course add a version number to your struct so when it needs upgrading you then have the fun of maintaining multiple versions?

    Do yourself a favour and use NSDictionary.

Share This Page