0

I am updating my app to 64 bit.

I save doc by looking at all the objects and saving them in a document.

32bit Object

@interface mySquare : NSObject
@property   int     someInt; 
@property   float   someFloat; 
@property   CGPoint     beginPos;
@property   CGPoint      endPos;
-(void) applyStrokeTypeAndColor:(CGContextRef)context;
@end

How I Save (Abstract Concept)

for (MyObjects *obj in self.objects)  {
     [obj archiveTo:file]; 
}

To read them (Abstract Concept)

for (int i = 0; i < cnt; i++) {
    NSString *clsName = [MyObjects objectNameOfData:file];

    MyObjects *obj = [NSClassFromString(clsName) new];
    [obj readFrom:file]; 
    if (self.targetView == MyView) {
        [self.objects addObject:obj];
    }

}

Suffice it to say, this method works. And has worked great for years for the type of app I have built. Reading an object, saving it, reading it back in and casting it to the correct class type.

If the file is created on 32 bit app it opens on the the "32 bit" version, they open fine.

After updating to 64 bit, files created in "64 bit" open fine, but the those created using the 32 bit method do not. The file is loaded and if I log out any information, I can see that each object is being read in, but, I am assuming losing data (obviously) in the progress.

64 bit Object

@interface mySquare : NSObject
@property   long        someInt;   //was int
@property   CGFloat     someFloat; //was float
@property   CGPoint     beginPos;
@property   CGPoint     endPos;
-(void) applyStrokeTypeAndColor:(CGContextRef)context;
@end

As you can see above, the only thing that changed with the 64 bit objects was the Reference Type.

I have built in a way to distinguish files created in my 32 bit vs 64 bit. I just changed the 64bit file extension to "myExt2" so the program knows which "version" the file was created in and prevent old versions of the app from even seeing the new 64 bit files.

I am afraid I am out of my league when in the realm.

How can I cast my 32-bit files (or in app convert them) to open in my 64-bit program? I can't send out an update of my app without legacy file support.

rmaddy
  • 314,917
  • 42
  • 532
  • 579
user-44651
  • 3,924
  • 6
  • 41
  • 87

1 Answers1

0

As we know from the comments, the 64bit app opens the old files fine, when using the code from 32bit app version. I'd suggest you keep the old code, renaming the class to something like mySquareOld. Then whenever your users try to open the old file do the following :

  1. Read the data using the old code
  2. Convert mySquareOld to mySquare
  3. Delete the old file
  4. Save mySquare under the same file name but with new structure.

Second step should be easy once the objects are deserialized, since int and float should fit nicely in long and CGFloat respectively.

Losiowaty
  • 7,911
  • 2
  • 32
  • 47
  • If I am going to use old 32 bit code to open files, why even develop 64 classes? Not trying to be difficult. I just don't understand – user-44651 Jun 13 '17 at 15:02
  • Well, if the app compiles fine for 64bit architecture and you tested it thoroughly and are confident that everything works fine, then it would seem that you don't need to do code changes (at least in this part of the app). I'd strongly advise you to test the values in `CGPoint` properties extra cautiously, since they use `CGFloat` internally for `x` and `y`, and if I'm not mistaken, `CGFloat` was a `typedef` for `float` on 32bit, and is a `typedef` for `double` on 64bit. – Losiowaty Jun 13 '17 at 19:55
  • Thanks. I get a lot of "loss of precision" warnings if I leave the classes objects as `int`s. Any recommendations? – user-44651 Jun 13 '17 at 19:57
  • That would most likely mean that somewhere in your code you are assigning something with bigger precision, a `long` (or `NSInteger`, since its a `typedef` for `long` on 64bit) to `someInt` - or, analogically a `double` or `CGFloat` to `someFloat`. you should address this warnings, as they may lead to some strange behavior. You can read more about loos of precision and how it works in [this answer](https://stackoverflow.com/a/13652624/765298) - although it is about `C` language, the idea is quite universal. – Losiowaty Jun 13 '17 at 20:11