Re: predefined macro iOS vs OS X
On Aug 17, 2013, at 19:01 , Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 17 août 2013 à 17:55, Marcel Weiher marcel.wei...@gmail.com a écrit : However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. You don't have to add explicit dependency to anything as NSGeometry.h already does that for you. Importing Foundation.h is enough to use CGRect on both OS X and iOS. That would be awesome and would mean I no longer need my PhoneGeometry.h hack. Alas, I just checked and did not find NSGeometry.h in the Foundation headers on iOS (and didn’t find NSRect or NSPoint anywhere either). Maybe I am missing something? Cheers, Marcel ___ 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: predefined macro iOS vs OS X
On Aug 18, 2013, at 6:28 AM, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 17, 2013, at 19:01 , Jean-Daniel Dupas devli...@shadowlab.org wrote: You don't have to add explicit dependency to anything as NSGeometry.h already does that for you. Importing Foundation.h is enough to use CGRect on both OS X and iOS. That would be awesome and would mean I no longer need my PhoneGeometry.h hack. Alas, I just checked and did not find NSGeometry.h in the Foundation headers on iOS (and didn’t find NSRect or NSPoint anywhere either). Maybe I am missing something? You have it backwards. Jean-Daniel was saying that CGRect is defined on OS X without having to explicitly import CoreGraphics headers. So use CGRect instead of NSRect. --Kyle Sluder ___ 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: predefined macro iOS vs OS X
On Aug 18, 2013, at 15:06 , Kyle Sluder k...@ksluder.com wrote: On Aug 18, 2013, at 6:28 AM, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 17, 2013, at 19:01 , Jean-Daniel Dupas devli...@shadowlab.org wrote: You don't have to add explicit dependency to anything as NSGeometry.h already does that for you. Importing Foundation.h is enough to use CGRect on both OS X and iOS. That would be awesome and would mean I no longer need my PhoneGeometry.h hack. Alas, I just checked and did not find NSGeometry.h in the Foundation headers on iOS (and didn’t find NSRect or NSPoint anywhere either). Maybe I am missing something? You have it backwards. Jean-Daniel was saying that CGRect is defined on OS X without having to explicitly import CoreGraphics headers. So use CGRect instead of NSRect. Ahh, crap, they did it backwards, seems to be the norm these days :-( I guess I’ll keep using PhoneGeometry.h :-) Cheers, Marcel ___ 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: predefined macro iOS vs OS X
On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h /PetPeeve ___ 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: predefined macro iOS vs OS X
On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h /PetPeeve ___ 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: predefined macro iOS vs OS X
I actually got one step (sorry for the pun) ahead as limited to what Cocoa’s Foundation and GNUstep’s Base have in common. That allows me to create code-compatible programs that builds and runs under both OS X (or iOS) and Linux. (In my company everything starts off in Objective-C and now with this limitation the porting cost is dropping drastically.) Example: CGIKit: https://github.com/xcvista/CGIKit (a FastCGI library for Objective-C, CGIKit.xcodeproj will build on OS X with embedded libfcgi and GNUmakefile will build on Linux with GNUstep with external libfcgi.) On Aug 17, 2013, at 23:52, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h /PetPeeve ___ 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/xcvista%40me.com This email sent to xcvi...@me.com ___ 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: predefined macro iOS vs OS X
Le 17 août 2013 à 17:55, Marcel Weiher marcel.wei...@gmail.com a écrit : On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. You don't have to add explicit dependency to anything as NSGeometry.h already does that for you. Importing Foundation.h is enough to use CGRect on both OS X and iOS. -- Jean-Daniel ___ 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: predefined macro iOS vs OS X
On Aug 17, 2013, at 18:03 , Maxthon Chan xcvi...@me.com wrote: On Aug 17, 2013, at 23:52, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h I actually got one step (sorry for the pun) ahead as limited to what Cocoa’s Foundation and GNUstep’s Base have in common. That allows me to create code-compatible programs that builds and runs under both OS X (or iOS) and Linux. (In my company everything starts off in Objective-C and now with this limitation the porting cost is dropping drastically.) Example: CGIKit: https://github.com/xcvista/CGIKit (a FastCGI library for Objective-C, CGIKit.xcodeproj will build on OS X with embedded libfcgi and GNUmakefile will build on Linux with GNUstep with external libfcgi.) Very cool, and I am definitely with you, though I have to admit I haven’t really kept in sync with GNUStep ( https://github.com/mpw/MPWFoundation/blob/master/GNUmakefile is a bit out of date), working more with Cocotron to get Linux compatibility. Cheers, Marcel ___ 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: predefined macro iOS vs OS X
Well I chose GNUstep for its longer history (it predates Cocoa, even OpenStep - in fact it is the second implementation of Application Kit, what would later become the libraries we now know as Foundation and AppKit, after NeXT.) and better ARC support. They have an impressive libobjc that combined what Apple and LLVM folks called libobjc4 (Objectve-C 2 runtime with ARC support) and libBlocksRuntime into one unit, and supports GCD very well. Also, LLVM folks ported what Apple contributed in LLDB debugger to support their runtime too. Also, they have rewrites of Core Foundation, Core Data, Core Graphics, WebObjects (in Objective-C) and more. On Aug 18, 2013, at 1:15, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 17, 2013, at 18:03 , Maxthon Chan xcvi...@me.com wrote: On Aug 17, 2013, at 23:52, Marcel Weiher marcel.wei...@gmail.com wrote: On Aug 16, 2013, at 19:04 , Kyle Sluder k...@ksluder.com wrote: Stop using NSRect in your method prototypes and just use CGRect. This is certainly pragmatic, effective advice. PetPeeve However…if you care as much about dependency management as I do (and chances are you don’t), and don’t have a direct dependency on CoreGraphics in that code (and chances are you do), then this is slightly stomach-churning, in addition to pragmatic and effective. Pulling in a dependency on CoreGraphics just to get those types is awful, in addition it makes it harder to make code that works on both Mac OS X and iOS. After going back and forth on this for quite some time, I decided to standardize on the Foundation types and have a tiny compatibility layer, which you can find on github: https://github.com/mpw/MPWFoundation/blob/master/Classes/PhoneGeometry.h I actually got one step (sorry for the pun) ahead as limited to what Cocoa’s Foundation and GNUstep’s Base have in common. That allows me to create code-compatible programs that builds and runs under both OS X (or iOS) and Linux. (In my company everything starts off in Objective-C and now with this limitation the porting cost is dropping drastically.) Example: CGIKit: https://github.com/xcvista/CGIKit (a FastCGI library for Objective-C, CGIKit.xcodeproj will build on OS X with embedded libfcgi and GNUmakefile will build on Linux with GNUstep with external libfcgi.) Very cool, and I am definitely with you, though I have to admit I haven’t really kept in sync with GNUStep ( https://github.com/mpw/MPWFoundation/blob/master/GNUmakefile is a bit out of date), working more with Cocotron to get Linux compatibility. Cheers, Marcel ___ 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: predefined macro iOS vs OS X
On Aug 16, 2013, at 10:04, Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. Or just define NS_BUILD_32_LIKE_64. Doing so will cause NSRect to be defined as a typedef for CGRect. -- Clark Smith Cox III clark@apple.com ___ 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: predefined macro iOS vs OS X
On Aug 17, 2013, at 4:52 PM, Clark Smith Cox III clark@apple.com wrote: On Aug 16, 2013, at 10:04, Kyle Sluder k...@ksluder.com wrote: Stop using NSRect in your method prototypes and just use CGRect. Or just define NS_BUILD_32_LIKE_64. Doing so will cause NSRect to be defined as a typedef for CGRect. Gerriet still needs to use CGRect in his APIs because he's compiling them for both iOS and Mac. And as the name implies, NS_BUILD_32_LIKE_64 is unnecessary if you're not targeting 32-bit OS X. --Kyle Sluder ___ 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
predefined macro iOS vs OS X
I have some code which is almost identical vor iOS and OS X. So I want to write something like: #ifdef SOME_THING // OS X NSRect someRect = ... #else // iOS CGRect someRect =... #endif But what to choose for SOME_THING? Gerriet. ___ 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: predefined macro iOS vs OS X
One thing to note: in the 64-bit run time, NSRect and CGRect are the same thing. Otherwise, what you want is #if TARGET_OS_IPHONE or #if !TARGET_OS_IPHONE On Aug 16, 2013, at 05:10 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I have some code which is almost identical vor iOS and OS X. So I want to write something like: #ifdef SOME_THING // OS X NSRect someRect = ... #else // iOS CGRect someRect =... #endif But what to choose for SOME_THING? Gerriet. ___ 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/rmann%40latencyzero.com This email sent to rm...@latencyzero.com -- Rick ___ 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: predefined macro iOS vs OS X
On 16 Aug 2013, at 19:17, Rick Mann rm...@latencyzero.com wrote: One thing to note: in the 64-bit run time, NSRect and CGRect are the same thing. Yes. But the Xcode does not know this and creates lots of warnings. Otherwise, what you want is #if TARGET_OS_IPHONE Very good. Just tried it, and it works perfectly. Thank you very much! Is this documented anywhere? Xcode seems not to know about this. On Aug 16, 2013, at 05:10 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I have some code which is almost identical vor iOS and OS X. So I want to write something like: #ifdef SOME_THING // OS X NSRect someRect = ... #else // iOS CGRect someRect =... #endif Kind regards, Gerriet. ___ 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: predefined macro iOS vs OS X
Well I’d go with a conditional like: #if TARGET_OS_IPHONE typedef CGRect NSRect; typedef CGSize NSSize; typedef CGPoint NSPoint; #define NSMakeRect CGRectMake #define NSMakePoint CGPointMake // etc #endif and go with NS* variants. On Aug 16, 2013, at 20:17, Rick Mann rm...@latencyzero.com wrote: One thing to note: in the 64-bit run time, NSRect and CGRect are the same thing. Otherwise, what you want is #if TARGET_OS_IPHONE or #if !TARGET_OS_IPHONE On Aug 16, 2013, at 05:10 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I have some code which is almost identical vor iOS and OS X. So I want to write something like: #ifdef SOME_THING // OS X NSRect someRect = ... #else // iOS CGRect someRect =... #endif But what to choose for SOME_THING? Gerriet. ___ 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/rmann%40latencyzero.com This email sent to rm...@latencyzero.com -- Rick ___ 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/xcvista%40me.com This email sent to xcvi...@me.com ___ 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: predefined macro iOS vs OS X
On Aug 16, 2013, at 6:51 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: Is this documented anywhere? Xcode seems not to know about this. Not sure where it is in the docs, but /usr/include/TargetConditionals.h, which defines this symbol and others, has a bunch of commentary. —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: predefined macro iOS vs OS X
On Aug 16, 2013, at 9:51 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 19:17, Rick Mann rm...@latencyzero.com wrote: One thing to note: in the 64-bit run time, NSRect and CGRect are the same thing. Yes. But the Xcode does not know this and creates lots of warnings. Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. --Kyle Sluder ___ 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: predefined macro iOS vs OS X
On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 9:51 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 19:17, Rick Mann rm...@latencyzero.com wrote: One thing to note: in the 64-bit run time, NSRect and CGRect are the same thing. Yes. But the Xcode does not know this and creates lots of warnings. Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Gerriet. ___ 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: predefined macro iOS vs OS X
On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. --Kyle Sluder ___ 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: predefined macro iOS vs OS X
On Aug 16, 2013, at 5:10 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I have some code which is almost identical vor iOS and OS X. So I want to write something like: #ifdef SOME_THING // OS X NSRect someRect = ... #else // iOS CGRect someRect =... #endif But what to choose for SOME_THING? You want TargetConditionals.h. http://sealiesoftware.com/blog/archive/2010/8/16/TargetConditionalsh.html -- 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: predefined macro iOS vs OS X
On 17 Aug 2013, at 01:33, Greg Parker gpar...@apple.com wrote: On Aug 16, 2013, at 5:10 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I have some code which is almost identical vor iOS and OS X. So I want to write something like: #ifdef SOME_THING // OS X NSRect someRect = ... #else // iOS CGRect someRect =... #endif But what to choose for SOME_THING? You want TargetConditionals.h. http://sealiesoftware.com/blog/archive/2010/8/16/TargetConditionalsh.html This is a truly amazing link. It really should be part of the documentation. Thanks a lot! Kind regards Gerriet. ___ 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: predefined macro iOS vs OS X
On 17 Aug 2013, at 00:04, Kyle Sluder k...@ksluder.com wrote: On Aug 16, 2013, at 12:41 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 16 Aug 2013, at 22:59, Kyle Sluder k...@ksluder.com wrote: Xcode does know this. But if you're building for 32-bit OS X, it will correctly complain. When I build for Mac OS X CGRect is accepted. But when I build for iOS then NSRect creates Use of undeclared identifier NSRect did you mean NSSet Stop using NSRect in your method prototypes and just use CGRect. Excellent idea. I have just starting doing this and already my code looks much better - many ifdef could be eliminated. Thanks a lot! Kind regards, Gerriet. ___ 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
