Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

zeppenwolf

macrumors regular
Original poster
Nov 17, 2009
129
3
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:

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 you’re compiling for 10.5+ then it doesn’t 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 isn’t 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...
 
Just define a name of your own choosing, in the pre-defined macros for the project.

Your OS is 10.2.8. It doesn't have Obj-C 2, and never will. Why are you trying to write code that will automatically adapt to something that will never happen?

http://en.wikipedia.org/wiki/YAGNI

Unless and until you upgrade your machine to something that actually has Obj-C 2, it isn't going to make any difference. When and if you do upgrade your machine (and your OS and tools), that's when you can worry about automatically defining the symbol. If you actually need to keep any of your old code at that point.

Frankly, I think your macros obfuscate more than clarify, nor do they add any functionality. You'd be better off just writing actual Obj-C 1 code for any new code, or translate existing Obj-C 2 source to Obj-C 1 source, since you have to rewrite it anyway. You can rewrite it with obscure macros or as plain ordinary Obj-C 1 code. Put any amount of lipstick on a pig, it still ain't a debutante.

When and if you do get to the point of needing to automatically define the symbol, it can still work with whatever pre-defined symbol you chose earlier:
Code:
#if __THE_REAL_AUTOMATIC_OBJC_2_MACRO
#define __OBJECTIVE_C_TWO_POINT_OH__ 1
#else
#define __OBJECTIVE_C_TWO_POINT_OH__ 0
#endif
And you really shouldn't be defining your own names that start with __ (two underbars). Those are specifically reserved for system-defined names.
 
If g++ is compiling an Objective-C source file __OBJC__ will be predefined by the compiler and assigned the value 1.

Additionally if the garbage collector is enabled __OBJC2__ will also be predefined by the compiler and assigned the value 1.
 
If g++ is compiling an Objective-C source file __OBJC__ will be predefined by the compiler and assigned the value 1.

Additionally if the garbage collector is enabled __OBJC2__ will also be predefined by the compiler and assigned the value 1.

Not the garbage collector; the new ABI. Non-fragile ivars, C++-compatible exceptions, etc...

x86-64 only.
 
man g++ under pages '−fobjc−gc'.

You can get a dump of predefined macro with something along the following from within the terminal:

echo "int main() {};" > tmp.mm;g++ -fobjc -dM -E temp.mm;rm temp.mm
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.