Re: Property synthesis trouble - 32 vs 64 bit builds

[Graham Cox]

> On 6 Jul 2016, at 7:10 AM, Jonathan Taylor  
> wrote:
> 
> Quicktime. My code has been 32-bit only since I first wrote it, because I 
> make use of the APIs in QuickTime/ImageCompression.h for encoding movies.


Not really quite on-topic, but if you are having to switch to a whole new API, 
a possible alternative is to use ffmpeg. You can just embed the binary in your 
app and wrap it in a NSTask. I just did this for a very specific video encoding 
requirement I had and it was (in my case) a far simpler exercise than learning 
the necessary AVFoundation API. I had it working in about an hour as opposed to 
probably several days, and most of that hour was figuring out how to correctly 
pass command line parameters to NSTask.

It might seem sagreligious to some not to use a native API if one is available, 
but OTOH, sometimes the best tools are the ones to hand.

—Graham



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

On 5 Jul 2016, at 22:22, "Gary L. Wade"  wrote:
> You might need to write some lower level stuff, but some of the things in 
> there can be done, albeit differently. Apple knows I've submitted a number of 
> bugs and incident reports to get codecs supported in later frameworks. Do the 
> same. It may happen.


... ah, and I've just seen this reply from Gary as well. That's good to know - 
maybe I should take a fresh look if I do commit to the switch to a 64-bit build.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

>> Quicktime.
> 
> Oh, you poor thing. That’s one nasty API. (Actually dozens of nasty APIs.) O_o

Yep. I rely on code that I worked out years ago, with the help of examples on 
the internet, and I do my best to leave that code untouched!

>> My code has been 32-bit only since I first wrote it, because I make use of 
>> the APIs in QuickTime/ImageCompression.h for encoding movies. It's my 
>> understanding (as of last time I checked) that no equivalent functionality 
>> is available in the newer APIs.
> 
> AVFoundation is supposed to be the replacement for QuickTime, and definitely 
> supports video encoding. I’ve only used it for audio, though, so I don’t know 
> the details of its video support.

Unless it has been enhanced, I think the support for proper compression was 
lacking, and as a result any generated movie files would be enormous.

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Gary L. Wade]

You might need to write some lower level stuff, but some of the things in there 
can be done, albeit differently. Apple knows I've submitted a number of bugs 
and incident reports to get codecs supported in later frameworks. Do the same. 
It may happen.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Jul 5, 2016, at 2:10 PM, Jonathan Taylor  
> wrote:
> 
> Quicktime. My code has been 32-bit only since I first wrote it, because I 
> make use of the APIs in QuickTime/ImageCompression.h for encoding movies. 
> It's my understanding (as of last time I checked) that no equivalent 
> functionality is available in the newer APIs.


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Jens Alfke]

> On Jul 5, 2016, at 2:10 PM, Jonathan Taylor  
> wrote:
> 
> Quicktime.

Oh, you poor thing. That’s one nasty API. (Actually dozens of nasty APIs.) O_o

> My code has been 32-bit only since I first wrote it, because I make use of 
> the APIs in QuickTime/ImageCompression.h for encoding movies. It's my 
> understanding (as of last time I checked) that no equivalent functionality is 
> available in the newer APIs.

AVFoundation is supposed to be the replacement for QuickTime, and definitely 
supports video encoding. I’ve only used it for audio, though, so I don’t know 
the details of its video support.

—Jens
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

Thanks everyone for your replies - some responses below:

On 5 Jul 2016, at 20:55, Greg Parker  wrote:
> A synthesized property must use one of the following types of storage:
> 1. An ivar in that class that @synthesize creates.
> 2. An ivar in that class that you defined yourself.
> 
> @synthesize on 32-bit macOS doesn't support #1. The problem is that 32-bit 
> macOS doesn't support non-fragile ivars. Allowing @synthesize to create ivars 
> would make it too easy to accidentally change ivar layout and break 
> compatibility.
> 
> No platform allows @synthesize to bind to a superclass ivar. That would make 
> it too easy to accidentally bind to an unrelated superclass ivar when you 
> really wanted to create a new ivar.

That last statement is a surprise to me. I had believed that the 32-bit code I 
posted was doing just that - MutableSettings binding its property to the ivar 
in ImmutableSettings. Certainly it's not clear to me how that statement *and* 
your statement that #1 is not supported on 32-bit could both be true (there is 
no backing ivar that I declare in the mutable subclass). I also ~think~ the 
code is working correctly on a 32-bit platform (and has been for several years).

I'm not meaning to be argumentative, just trying to get my head around this :-) 
  

On 5 Jul 2016, at 18:12, Quincey Morris  
wrote:
> I’d recommend a different approach, especially if there’s no behavior for the 
> property other than getting or setting an instance variable (which I assume, 
> because you’re trying to use synthesis):
> [...]
> It may sound weird to make the property (internally) settable in an immutable 
> class, but the instance variable is always modifiable in the superclass 
> anyway, so it’s kinda the same thing. Having a private setter there doesn’t 
> really change anything.

Interesting. It does indeed sound weird, but I agree that it shouldn't actually 
be any different to what I'm currently doing. I might just give that a go!

Does this approach have any specific advantages compared to the approach 
suggested by Keary (i.e. basically don't do any synthesis, and just write a 
getter in the base class and a setter in the subclass)?

> Side note:
> 
> Why are you even supporting 32-bit architectures on the Mac? The only good 
> reason I can think of is if you must still update users running OS X 10.5. 
> Users of 10.6.8 and above can (and should) use 64-bit versions of apps.

Quicktime. My code has been 32-bit only since I first wrote it, because I make 
use of the APIs in QuickTime/ImageCompression.h for encoding movies. It's my 
understanding (as of last time I checked) that no equivalent functionality is 
available in the newer APIs. That, plus a big dose of "if it ain't broke, don't 
fix it", as a scientist for whom this Cocoa application of mine is a very 
helpful tool for me and my colleagues, but is just a means to an end rather 
than a product in its own right.

I have only now started looking at 64 bit (knowing I am losing the quicktime 
functionality) because I wanted to look at interfacing with libraries that are 
64-bit only.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Greg Parker]

> On Jul 5, 2016, at 9:27 AM, Jens Alfke  wrote:
> 
>> On Jul 5, 2016, at 4:36 AM, Jonathan Taylor  
>> wrote:
>> 
>> It surprises me that I have to write different synthesis code for 32- or 
>> 64-bit builds
> 
> It’s because they use different Obj-C runtimes. For compatibility reasons, 
> 32-bit Mac apps still use the old runtime, while 64-bit apps (and all iOS 
> apps) get to use the new improved runtime.
> 
> One of the differences between the runtimes is how instance variables are 
> accessed, and I think your particular situation — trying to synthesize a 
> property backed by an _inherited_ ivar — is an edge case.

A synthesized property must use one of the following types of storage:
1. An ivar in that class that @synthesize creates.
2. An ivar in that class that you defined yourself.

@synthesize on 32-bit macOS doesn't support #1. The problem is that 32-bit 
macOS doesn't support non-fragile ivars. Allowing @synthesize to create ivars 
would make it too easy to accidentally change ivar layout and break 
compatibility.

No platform allows @synthesize to bind to a superclass ivar. That would make it 
too easy to accidentally bind to an unrelated superclass ivar when you really 
wanted to create a new ivar.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Quincey Morris]

On Jul 5, 2016, at 04:36 , Jonathan Taylor  
wrote:
> 
> @interface ImmutableSettings : NSObject
> {
>BOOL_myFlag;
> }
> @property (readonly) BOOL myFlag;
> @end
> 
> @interface MutableSettings : ImmutableSettings
> @property (readwrite) BOOL myFlag;
> @end
> 
> @implementation ImmutableSettings
> 
> -(id)init
> {
>if (!(self = [super init]))
>return nil;
>_myFlag = true;
>return self;
> }
> @synthesize myFlag = _myFlag;
> 
> @end

You have to remember that there’s no magic behind properties. Each class has 
(potentially) a getter method, a setter method and an instance variable, which 
makes a total of 6 (potential) things across 2 classes. When one is a subclass 
of the other, that’s 3 opportunities for conflicts and ambiguities about which 
thing is meant at any given place in the code. Different versions of the 
compiler detect and complain about different ambiguities.

I’d recommend a different approach, especially if there’s no behavior for the 
property other than getting or setting an instance variable (which I assume, 
because you’re trying to use synthesis):

— In ImmutableSettings.h, declare “myFlag” as a readonly property. This is its 
public definition.

— In ImmutableSettings.m, add a class extension “@interface ImmutableSettings 
()” that redeclares “myFlag” as readwrite.

— Synthesize the property in ImmutableSettings.m, producing both getter and 
setter. Note, however, that the setter is not available publicly.

— In MutableSettings.h, redeclare “myFlag” as a readwrite property. This makes 
it available publicly.

— In MutableSettings.m, say “@dynamic myFlag;” to indicate that the accessors 
will be provided at runtime (by the parent class in this case). If you needed 
custom behavior in the setter, you could simply provide an override to 
setMyFlag: too. Do not synthesize the property in this class.

It may sound weird to make the property (internally) settable in an immutable 
class, but the instance variable is always modifiable in the superclass anyway, 
so it’s kinda the same thing. Having a private setter there doesn’t really 
change anything.

Alternative approach:

If the “myFlag” property is always and forever YES in the superclass, then 
don’t synthesize anything in that class, but write a custom setter that simply 
return YES. That saves a little bit of memory by not having an instance 
variable at all. The just synthesize the readwrite property in the subclass in 
the normal way. In the subclass, synthesize the readwrite property normally.

Side note:

Why are you even supporting 32-bit architectures on the Mac? The only good 
reason I can think of is if you must still update users running OS X 10.5. 
Users of 10.6.8 and above can (and should) use 64-bit versions of apps.

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Jens Alfke]

> On Jul 5, 2016, at 4:36 AM, Jonathan Taylor  
> wrote:
> 
> It surprises me that I have to write different synthesis code for 32- or 
> 64-bit builds

It’s because they use different Obj-C runtimes. For compatibility reasons, 
32-bit Mac apps still use the old runtime, while 64-bit apps (and all iOS apps) 
get to use the new improved runtime.

One of the differences between the runtimes is how instance variables are 
accessed, and I think your particular situation — trying to synthesize a 
property backed by an _inherited_ ivar — is an edge case.

You could ask this on the objc-language mailing list to see if any gurus can 
weigh in.

—Jens
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

Thanks for that information - that’s very helpful. It sounds from what you are 
saying as if there is nothing wrong with me redefining the *property* in the 
subclass (as read-write), but that it’s just the synthesis itself that is the 
problem? Assuming that is the case, I can easily(*) rectify that by writing 
explicit setters/getters, so I will do that.

(*) there are rather a lot of these properties in the actual original code, but 
it just involves a lot of typing!


On 5 Jul 2016, at 16:12, Keary Suska  wrote:

> 
>> On Jul 5, 2016, at 5:36 AM, Jonathan Taylor  
>> wrote:
>> 
>> I have a problem with property synthesis in my code, which I hope somebody 
>> can advise on. I find I have to write different property synthesis code for 
>> 32- or 64-bit builds in order to avoid compiler errors.
>> 
>> A minimal demonstration of the problem can be found below - build as part of 
>> a fresh project on Xcode 5 or 6, with ARC disabled. It surprises me that I 
>> have to write different synthesis code for 32- or 64-bit builds - and this 
>> then makes me worry that I am doing something more fundamentally wrong. Can 
>> anyone comment (or explain)?
>> 
>> [I appreciate that this code may be old-fashioned in style - I am not even 
>> sure what is or is not the recommended style these days. It seems to work 
>> though - and, importantly, as far as I can tell the synthesized property 
>> myFlag on MutableSettings *does* map to the same backing variable, even on a 
>> 64-bit build where I am not able to specify the backing variable in the 
>> synthesis statement]
> 
> 32 vs 64 is likely coincidental, and probably has more to do with compiler 
> differences. I.e., at that time, there were additional compiler “features” 
> for 64 bit vs 32 bit. So my thought is that what you are doing is wrong in 
> both cases, but you are simply getting different compiler errors.
> 
> The essential issue I believe is that you cannot re-synthesize in a subclass. 
> You will have to specify the setter explicitly. The issue in the second 
> (64-bit) case is that when you specify @synthesize with an instance variable 
> you are specifying a *new* instance variable on that class, but the compiler 
> correctly warns you that that instance variable has already been defined in 
> the superclass and therefore cannot also be defined in the subclass. The 32 
> bit compiler seems to be letting you get away with this error, but it could 
> have horrible unintended consequences.

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property synthesis trouble - 32 vs 64 bit builds

[Keary Suska]

> On Jul 5, 2016, at 5:36 AM, Jonathan Taylor  
> wrote:
> 
> I have a problem with property synthesis in my code, which I hope somebody 
> can advise on. I find I have to write different property synthesis code for 
> 32- or 64-bit builds in order to avoid compiler errors.
> 
> A minimal demonstration of the problem can be found below - build as part of 
> a fresh project on Xcode 5 or 6, with ARC disabled. It surprises me that I 
> have to write different synthesis code for 32- or 64-bit builds - and this 
> then makes me worry that I am doing something more fundamentally wrong. Can 
> anyone comment (or explain)?
> 
> [I appreciate that this code may be old-fashioned in style - I am not even 
> sure what is or is not the recommended style these days. It seems to work 
> though - and, importantly, as far as I can tell the synthesized property 
> myFlag on MutableSettings *does* map to the same backing variable, even on a 
> 64-bit build where I am not able to specify the backing variable in the 
> synthesis statement]

32 vs 64 is likely coincidental, and probably has more to do with compiler 
differences. I.e., at that time, there were additional compiler “features” for 
64 bit vs 32 bit. So my thought is that what you are doing is wrong in both 
cases, but you are simply getting different compiler errors.

The essential issue I believe is that you cannot re-synthesize in a subclass. 
You will have to specify the setter explicitly. The issue in the second 
(64-bit) case is that when you specify @synthesize with an instance variable 
you are specifying a *new* instance variable on that class, but the compiler 
correctly warns you that that instance variable has already been defined in the 
superclass and therefore cannot also be defined in the subclass. The 32 bit 
compiler seems to be letting you get away with this error, but it could have 
horrible unintended consequences.

> @interface ImmutableSettings : NSObject
> {
>BOOL_myFlag;
> }
> @property (readonly) BOOL myFlag;
> @end
> 
> @interface MutableSettings : ImmutableSettings
> @property (readwrite) BOOL myFlag;
> @end
> 
> @implementation ImmutableSettings
> 
> -(id)init
> {
>if (!(self = [super init]))
>return nil;
>_myFlag = true;
>return self;
> }
> @synthesize myFlag = _myFlag;
> 
> @end
> 
> @implementation MutableSettings
> // This is very odd - I get errors on 64-bit builds if I specify a backing 
> variable for synthesis,
> // but I get errors on 32-bit builds if I *don't* specify a backing variable!?
> #if defined(__x86_64__)
>// On 32-bit builds I get an error here:
>// "Synthesized property 'myFlag' must either be named the same as a 
> compatible instance variable or must explicitly name an instance variable"
>@synthesize myFlag;
> #else
>// On 64-bit builds I get an error here:
>// "Property 'myFlag' attempting to use instance variable '_myFlag' 
> declared in super class 'ImmutableSettings'"
>@synthesize myFlag = _myFlag;
> #endif

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Property synthesis trouble - 32 vs 64 bit builds

[Jonathan Taylor]

Hi all,

I have a problem with property synthesis in my code, which I hope somebody can 
advise on. I find I have to write different property synthesis code for 32- or 
64-bit builds in order to avoid compiler errors.

A minimal demonstration of the problem can be found below - build as part of a 
fresh project on Xcode 5 or 6, with ARC disabled. It surprises me that I have 
to write different synthesis code for 32- or 64-bit builds - and this then 
makes me worry that I am doing something more fundamentally wrong. Can anyone 
comment (or explain)?

[I appreciate that this code may be old-fashioned in style - I am not even sure 
what is or is not the recommended style these days. It seems to work though - 
and, importantly, as far as I can tell the synthesized property myFlag on 
MutableSettings *does* map to the same backing variable, even on a 64-bit build 
where I am not able to specify the backing variable in the synthesis statement]

Cheers
Jonny


@interface ImmutableSettings : NSObject
{
BOOL_myFlag;
}
@property (readonly) BOOL myFlag;
@end

@interface MutableSettings : ImmutableSettings
@property (readwrite) BOOL myFlag;
@end

@implementation ImmutableSettings

-(id)init
{
if (!(self = [super init]))
return nil;
_myFlag = true;
return self;
}
@synthesize myFlag = _myFlag;

@end

@implementation MutableSettings
// This is very odd - I get errors on 64-bit builds if I specify a backing 
variable for synthesis,
// but I get errors on 32-bit builds if I *don't* specify a backing variable!?
#if defined(__x86_64__)
// On 32-bit builds I get an error here:
// "Synthesized property 'myFlag' must either be named the same as a 
compatible instance variable or must explicitly name an instance variable"
@synthesize myFlag;
#else
// On 64-bit builds I get an error here:
// "Property 'myFlag' attempting to use instance variable '_myFlag' 
declared in super class 'ImmutableSettings'"
@synthesize myFlag = _myFlag;
#endif

@end

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com