I'm running ObjC 1.0, with PB 2.1 and gcc3...
Once upon a time, ( a time when there was only ObjC 1 ), I followed and compiled the "Currency Converter" tutorial, and it went fine... except that ObjC gave me a real headache. So I put ObjC on the backburner.
( I guess I'll always be a C++ kinda guy!! )
Time passes, here we are today, and I decide to make the effort again-- can't fight progress-- and I work through the CC tutorial again...
But this time it's in ObjC 2. Well that's fine too! I think to myself that it would be good/fun to define a few CPP macros such that I can gently massage whatever ObjC 2 code I download to compile in my ObjC 1 environment, such that, when and if I ever compile the same code in ObjC 2, it will still compile fine. IOW, they are macros to "bridge" from ObjC 1 to 2.
Here is an example of what I have in mind:
And those "work" perfectly, in the sense that depending on the CPP symbol, it comes out to be exactly the ObjC 1 or 2 code that one wants.
So the only problem is what CPP symbol to use to identify the existence of ObjC 2.
Obviously, I cannot determine that in my ObjC 1 environment, (!), So I googled around, and was largely left still bewildered. But I found this:
>OBJC_API_VERSION
>This is set based on the low-level runtime API available. OBJC_API_VERSION==0 is the legacy API. OBJC_API_VERSION==2 means the function-based API added in Leopard is available. This is closer to what you want; it helps because it will disallow the new syntax when the deployment target is pre-Leopard, but if youre compiling for 10.5+ then it doesnt tell you whether your compiler knows about the new syntax.
>
>__OBJC2__
>This is set based on the ABI version (i.e. the metadata format on disk). This distinguishes between the legacy (i386+ppc) version and the modern (x86_64+ppc64) version. This isnt what you want.
>
>You could use OBJC_API_VERSION if your supported combinations are:
>* Old compiler with deployment target older than Leopard
>* New compiler with any deployment target
( From http://jongampark.wordpress.com/2008/04/26/objc_api_version-and-__objc2__/ )
Eh... I don't quite get what he's saying there. I think I've made it clear what I'm trying to do, which seems to me the "obvious" thing...
Is is truly as complicated or intractable as he's saying? I'm either compiling 1 or 2... Can't it be that simple? Please?!? Any clue appreciated...
Once upon a time, ( a time when there was only ObjC 1 ), I followed and compiled the "Currency Converter" tutorial, and it went fine... except that ObjC gave me a real headache. So I put ObjC on the backburner.
( I guess I'll always be a C++ kinda guy!! )
Time passes, here we are today, and I decide to make the effort again-- can't fight progress-- and I work through the CC tutorial again...
But this time it's in ObjC 2. Well that's fine too! I think to myself that it would be good/fun to define a few CPP macros such that I can gently massage whatever ObjC 2 code I download to compile in my ObjC 1 environment, such that, when and if I ever compile the same code in ObjC 2, it will still compile fine. IOW, they are macros to "bridge" from ObjC 1 to 2.
Here is an example of what I have in mind:
Code:
#if __OBJECTIVE_C_TWO_POINT_OH__
#define xPROPERTY_RD( type, name ) \
@property(read) type , name ;
#define xPROPERTY_WR( type, name ) \
@property(write) type , name ;
#define xPROPERTY_RW( type, name ) \
@property(readwrite) type , name ;
#else
#define xPROPERTY_RD( type, name ) \
-(type)name;
#define xPROPERTY_WR( type, name ) \
-(void)set_ ## name:(type)new_ ## name ;
#define xPROPERTY_RW( type, name ) \
-(type)name; \
-(void)set_ ## name:(type)new_ ## name ;
#endif
And those "work" perfectly, in the sense that depending on the CPP symbol, it comes out to be exactly the ObjC 1 or 2 code that one wants.
So the only problem is what CPP symbol to use to identify the existence of ObjC 2.
Obviously, I cannot determine that in my ObjC 1 environment, (!), So I googled around, and was largely left still bewildered. But I found this:
>OBJC_API_VERSION
>This is set based on the low-level runtime API available. OBJC_API_VERSION==0 is the legacy API. OBJC_API_VERSION==2 means the function-based API added in Leopard is available. This is closer to what you want; it helps because it will disallow the new syntax when the deployment target is pre-Leopard, but if youre compiling for 10.5+ then it doesnt tell you whether your compiler knows about the new syntax.
>
>__OBJC2__
>This is set based on the ABI version (i.e. the metadata format on disk). This distinguishes between the legacy (i386+ppc) version and the modern (x86_64+ppc64) version. This isnt what you want.
>
>You could use OBJC_API_VERSION if your supported combinations are:
>* Old compiler with deployment target older than Leopard
>* New compiler with any deployment target
( From http://jongampark.wordpress.com/2008/04/26/objc_api_version-and-__objc2__/ )
Eh... I don't quite get what he's saying there. I think I've made it clear what I'm trying to do, which seems to me the "obvious" thing...
Is is truly as complicated or intractable as he's saying? I'm either compiling 1 or 2... Can't it be that simple? Please?!? Any clue appreciated...