gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64bit changes to gui


From: Richard Frith-Macdonald
Subject: Re: 64bit changes to gui
Date: Sun, 17 Feb 2013 13:02:21 +0000

On 17 Feb 2013, at 11:33, Fred Kiefer wrote:

> Now that I am almost through with the changes to CGFloat, NSInteger and 
> NSUInteger in gui I realized that I did not think about coding. When the size 
> of an instance variable changes from int to NSInteger what should happen to 
> the coding/decoding code? Lets take the tag of an NSControl as the example. 
> The old -initWithCoder: code may look something like this:
> 
>      [aDecoder decodeValueOfObjCType: @encode(int) at: &_tag];
> 
> Now _tag no longer is an int, is now is an NSInteger. Will that code still 
> work?
> Should we change it to @encode(NSInteger)? (I think that is was base did) But 
> that will be something different depending on the machine the code runs on? 
> Is the coding mechanism able to handle that? And will this work for CGFloat 
> as well? And what about old archives, e.g. Gorm files?
> 
> For the last batches of changes I no longer changed the types of the instance 
> variables. That is a valid workaround, but only delays the decision what to 
> do. Using local variables of the old type for coding/decoding would also 
> work, but again looks wrong to me.

NSArchive/NSUnarchiver is supposed to cope with size differences between 
architectures automatically, but I'm not sure it will cope with different types 
without objecting (though I guess, if it doesn't,  we could make it do so).
That is, if we encode a 32bit int on one machine, it's ok to decode it as a 
64bit int, and if we encode a 64bit int, we can decode it as a 32bit int (as 
long as the original value can fit in a 32bit variable).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]