__objective_c_two_point_oh__???__

Discussion in 'Mac Programming' started by zeppenwolf, Dec 16, 2009.

  1. zeppenwolf macrumors regular

    zeppenwolf

    Joined:
    Nov 17, 2009
    #1
    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...
     
  2. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #2
    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.
     
  3. lloyddean macrumors 6502a

    Joined:
    May 10, 2009
    Location:
    Des Moines, WA
    #3
    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.
     
  4. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #4
    Not the garbage collector; the new ABI. Non-fragile ivars, C++-compatible exceptions, etc...

    x86-64 only.
     
  5. lloyddean macrumors 6502a

    Joined:
    May 10, 2009
    Location:
    Des Moines, WA
    #5
    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
     

Share This Page