macOS [myUserDefaults storeThisStruct:oleStyleCStruct]?

[zeppenwolf]

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... )

 

[Sydde]

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.

 

[chown33]

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.

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).

 

[Sydde]

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).

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.

 

[gnasher729]

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... )

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.