Re: Xcode 5 Obj-C++
On Jan 30, 2014, at 2:14 PM, Jens Alfke j...@mooseyard.com wrote: And C++ partisans would tell you that many of these things are limitations of the usual C++ runtimes, not the language itself, but I'm not aware of any current runtimes that avoid them. I bet those same partisans would be the first to the barricades to complain about the performance downsides of any C++ runtime implementation that did try to improve ABI fragility. -- 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/altotest1%40aol.com This email sent to altote...@aol.com On Jan 30, 2014, at 2:14 PM, Jens Alfke j...@mooseyard.com wrote: And C++ partisans would tell you that many of these things are limitations of the usual C++ runtimes, not the language itself, but I'm not aware of any current runtimes that avoid them. I bet those same partisans would be the first to the barricades to complain about the performance downsides of any C++ runtime implementation that did try to improve ABI fragility. -- 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/altotest1%40aol.com This email sent to altote...@aol.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: Xcode 5 Obj-C++
On 30 Jan 2014, at 4:14 PM, Jens Alfke j...@mooseyard.com wrote: And C++ partisans would tell you that many of these things are limitations of the usual C++ runtimes, not the language itself, but I'm not aware of any current runtimes that avoid them. For reference, see http://en.wikipedia.org/wiki/No_true_scotsman. — F ___ 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: Xcode 5 Obj-C++
On Jan 30, 2014, at 3:56 PM, Greg Parker gpar...@apple.com wrote: I bet those same partisans would be the first to the barricades to complain about the performance downsides of any C++ runtime implementation that did try to improve ABI fragility. Well, I don't know about that. But it would certainly be worthless to combine the baroque complexity of C++ with the dispatch performance of Java... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Xcode 5 Obj-C++
On 30 Jan 2014, at 00:42, Jens Alfke j...@mooseyard.com wrote: Anyone exposing a C++ API in a dynamic library is nuts, IMHO. What is it that makes C++ so unsuited to code sharing? Objective-C has great clarity of purpose (send a guy a message) and openness. Perhaps this is what makes it a great base for building dynamic systems (which is what UI driven applications generally are). If I need a computational engine within such a dynamic system (say I want to solve the Cutting Stock Problem) then C++ can supply focussed performance. Jonathan ___ 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: Xcode 5 Obj-C++
I too don’t get it. And isn’t all this message passing pretty much the same as calling methods in classes, just like you’d do in Java, C# or C++? On 30 Jan 2014, at 12:49, jonat...@mugginsoft.com wrote: On 30 Jan 2014, at 00:42, Jens Alfke j...@mooseyard.com wrote: Anyone exposing a C++ API in a dynamic library is nuts, IMHO. What is it that makes C++ so unsuited to code sharing? Objective-C has great clarity of purpose (send a guy a message) and openness. Perhaps this is what makes it a great base for building dynamic systems (which is what UI driven applications generally are). If I need a computational engine within such a dynamic system (say I want to solve the Cutting Stock Problem) then C++ can supply focussed performance. Jonathan ___ 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/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Xcode 5 Obj-C++
On 30 Jan 2014, at 11:53, Rui Pacheco rui.pach...@gmail.com wrote: And isn’t all this message passing pretty much the same as calling methods in classes, just like you’d do in Java, C# or C++? I would say that message sending is very different indeed: https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ObjCRuntimeGuide/Articles/ocrtHowMessagingWorks.html An Obj-C can load code dynamically at run time see: NSBundle -load. This makes it possible for an Obj-C object to modify the messages that it can respond to at run time. This may sound rather abstract but it is extremely useful for writing extensible applications that load up their functionality from plugin bundles. You can also load frameworks dynamically in this way - though it is more common to use the dynamic linker. A lot of Cocoa based languages and Cocoa bridges use this technique to access framework based functionality. The possible behaviours of a C# or C++ are largely defined at compile time. The actual behaviour of an Objective-C application will only be revealed at runtime. Jonathan ___ 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: Xcode 5 Obj-C++
When writing code you get the impression that you’re just calling methods. The type system may make the language more malleable, but when writing normal Core Data driven apps, you’re calling methods on objects. And I wonder if some of the things you highlighted couldn’t be done with well defined interfaces when using other languages. On 30 Jan 2014, at 13:10, jonat...@mugginsoft.com wrote: On 30 Jan 2014, at 11:53, Rui Pacheco rui.pach...@gmail.com wrote: And isn’t all this message passing pretty much the same as calling methods in classes, just like you’d do in Java, C# or C++? I would say that message sending is very different indeed: https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ObjCRuntimeGuide/Articles/ocrtHowMessagingWorks.html An Obj-C can load code dynamically at run time see: NSBundle -load. This makes it possible for an Obj-C object to modify the messages that it can respond to at run time. This may sound rather abstract but it is extremely useful for writing extensible applications that load up their functionality from plugin bundles. You can also load frameworks dynamically in this way - though it is more common to use the dynamic linker. A lot of Cocoa based languages and Cocoa bridges use this technique to access framework based functionality. The possible behaviours of a C# or C++ are largely defined at compile time. The actual behaviour of an Objective-C application will only be revealed at runtime. Jonathan ___ 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/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Xcode 5 Obj-C++
Le 30 janv. 2014 à 12:49, jonat...@mugginsoft.com a écrit : On 30 Jan 2014, at 00:42, Jens Alfke j...@mooseyard.com wrote: Anyone exposing a C++ API in a dynamic library is nuts, IMHO. What is it that makes C++ so unsuited to code sharing? We're not talking about code sharing, we are talking about dynamic library. It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. And I'm not even mentioning the fact that it is possible to build incompatible code from the same sources, depending the C++ features you enable (RTTI, …) The problem is limited with STL as most of it is just templates and the STL dylib itself contains very few code. While trying to expose a stable API and ABI in a dynamic library is possible, it is very complex or require some nasty construct like pimpl (which does not solve the virtual method issues). Objective-C has great clarity of purpose (send a guy a message) and openness. Perhaps this is what makes it a great base for building dynamic systems (which is what UI driven applications generally are). If I need a computational engine within such a dynamic system (say I want to solve the Cutting Stock Problem) then C++ can supply focussed performance. Jonathan ___ 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/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- 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: Xcode 5 Obj-C++
The recent flood of language philosophy is informative and interesting but doesn't address the issues I am interested in. My case is one of using the C++ std lib for the containers to work with traversing a special DAG graph. I've not found any C or Obj-C code that provides those and I see no reason to write them myself when C++ has them. On 2014-01-29, at 12:13 PM, Abdul Sowayan asowa...@vectorworks.net wrote: Are there any current docs that my search didn't find and that you can point me to? Or advice you can offer to help me? Well, I’m not clear as to what information you’re trying to find. Can you elaborate? Abdul In answer to Abdul's question there a a few things that immediately come to mind: The 2005 paper by Josh Anon (I have a pdf) mentions (0) The next thing to notice is that we’re mixing #import and #include directives here. It’s not a problem at all for the compiler. In fact, we could use: #import iostream and things would be fine. Actually, using #import is preferable to #include, because #import automatically makes sure the file’s only included once as opposed to having to #ifdef files we #include. Still true? (1) Before we begin coding, note that Objective-C++ classes, protocols, and categories cannot be declared within a separate namespace (nor can a C++ namespace be declared within an Objective-C++ object) Everything must be within the global namespace. Obviously true - no namespaces in Obj-C. (2) Just make sure to link against libstdc++ and Cocoa (or Foundation) in your Xcode project when you write your own code. Naturally. (3) Notice that we’ve intermixed Objective-C’s reference counting memory management with C++’s memory management. We cannot call delete on an Objective-C object, and we cannot call -release on a C++ variable. True even with ARC. (4) When do we need to use ifdef cplusplus or ifdef objc these days? etc... thanks Peter ___ 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: Xcode 5 Obj-C++
On 30 Jan 2014, at 01:28, Eric Wing ewmail...@gmail.com wrote: - Often when comparing Obj-C vs. C++, method dispatch is one of the main culprits for the performance difference. But don't forget, Obj-C is a pure superset of C and you can always use good old C to get the same performance benefits if you don't need/want the Obj-C features. Other really high performance situations deal with cache and memory layout and it turns out that much of the C++ standard library is not well suited for dealing with this and going back to POD types and essentially C (if not assembly) is often better for performance. Well, I'd rather use a barely-OO language like C++ than go down to procedural with C++ and get all those buffer overruns back ... -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ 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: Xcode 5 Obj-C++
On 30 Jan 2014, at 12:49, jonat...@mugginsoft.com wrote: On 30 Jan 2014, at 00:42, Jens Alfke j...@mooseyard.com wrote: Anyone exposing a C++ API in a dynamic library is nuts, IMHO. What is it that makes C++ so unsuited to code sharing? In short, method look-up depends on order of methods (so deleting a method breaks calls to all methods below it) and it suffers the fragile base class problem both for instance variables *and* methods. With the classic runtime, ObjC only had fragile base classes for ivars, since method lookup goes by SEL. With the modern runtime (iOS or Mac-64-bit), not even that anymore. -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ 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: Xcode 5 Obj-C++
On 30 Jan 2014, at 12:53, Rui Pacheco rui.pach...@gmail.com wrote: I too don’t get it. And isn’t all this message passing pretty much the same as calling methods in classes, just like you’d do in Java, C# or C++? No, they're very different. If you're curious, I blogged how C++ dispatches method calls under the hood in this article: http://orangejuiceliberationfront.com/runtime-time/ The sample code included with it implements the ObjC approach of actually looking stuff up by name. -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ 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: Xcode 5 Obj-C++
On 30 Jan 2014, at 14:35, Peter Teeson ptee...@icloud.com wrote: The recent flood of language philosophy is informative and interesting but doesn't address the issues I am interested in. My case is one of using the C++ std lib for the containers to work with traversing a special DAG graph. I've not found any C or Obj-C code that provides those and I see no reason to write them myself when C++ has them. On 2014-01-29, at 12:13 PM, Abdul Sowayan asowa...@vectorworks.net wrote: Are there any current docs that my search didn't find and that you can point me to? Or advice you can offer to help me? Well, I’m not clear as to what information you’re trying to find. Can you elaborate? Abdul In answer to Abdul's question there a a few things that immediately come to mind: The 2005 paper by Josh Anon (I have a pdf) mentions (0) The next thing to notice is that we’re mixing #import and #include directives here. It’s not a problem at all for the compiler. In fact, we could use: #import iostream and things would be fine. Actually, using #import is preferable to #include, because #import automatically makes sure the file’s only included once as opposed to having to #ifdef files we #include. Still true? Sure. They both just paste the code into the file. It's just that #import checks whether it already did the file in this compilation unit, #include doesn't. (1) Before we begin coding, note that Objective-C++ classes, protocols, and categories cannot be declared within a separate namespace (nor can a C++ namespace be declared within an Objective-C++ object) Everything must be within the global namespace. Obviously true - no namespaces in Obj-C. Is that a typo that it says Objective-C*++*? It should say Objective-C classes. C++ classes in ObjC++ can be in namespaces. Objective-C classes in ObjC++ files can't (and clang actually makes that an error, while GCC just ignored the namespace). There is no such thing as an Objective-C++ class. That's one of the main distinctions, both class systems are separate. (3) Notice that we’ve intermixed Objective-C’s reference counting memory management with C++’s memory management. We cannot call delete on an Objective-C object, and we cannot call -release on a C++ variable. True even with ARC. Although ARC works on ObjC pointers in ivars of C++ objects. (And since C++ objects are the same as structs to the C++ compiler, they also work on structs under the ObjC++ compiler) (4) When do we need to use ifdef cplusplus or ifdef objc these days? You use #ifdef __cplusplus when you plan to use C++ code (including those darned extern C statements) in headers that get included by C or ObjC source files. You use #ifdef __OBJC__ when you plan to use ObjC code in headers that get included in C++ or C source files. Also keep in mind that you can't just #ifdef out a method in a C++ class that takes an ObjC argument, as that will have the C++ file get a different offset for all following functions than the ObjC++ file. Also, since C++ overloads by type, You can't change the type of an ivar or parameter to a method or function, because then it will get a different name. I go into more detail about all this in the NSBrief podcast, just listen to that. etc... Too vague :-p -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ 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: Xcode 5 Obj-C++
On 30 Jan 2014, at 15:09, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 30 Jan 2014, at 01:28, Eric Wing ewmail...@gmail.com wrote: - Often when comparing Obj-C vs. C++, method dispatch is one of the main culprits for the performance difference. But don't forget, Obj-C is a pure superset of C and you can always use good old C to get the same performance benefits if you don't need/want the Obj-C features. Other really high performance situations deal with cache and memory layout and it turns out that much of the C++ standard library is not well suited for dealing with this and going back to POD types and essentially C (if not assembly) is often better for performance. Well, I'd rather use a barely-OO language like C++ than go down to procedural with C++ and get all those buffer overruns back ... procedural with *C* I meant. -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ 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: Xcode 5 Obj-C++
Hi, Language philosophy aside, our application is a largish cross platform (Mac, Windows, Linux) application written in C++. The UI framework uses Cocoa for the Mac back end, which means we're using Objective-C++ to interface with Cocoa. I've recently, at long last, been able to upgrade from Xcode 3 to Xcode 5. I had to make very few changes to the Objective-C++ code to get it to work. In fact it was so minor I've forgotten what it was exactly, something to do with the way I was making forward declarations of some Objective-C objects in headers that were shared by C++ and Objective-C++ code IIRC. Anyway, it wasn't any big drama. All my work was based on the various Objective-C++ resources available in late 2010, which was when I ported the UI framework to Cocoa from Carbon. There are some newer language features such as ARC which I'm not using, so I don't know what effect that might have. Essentially though, Xcode 5 and Objective-C++ are no problem. Regards, Jo Meder ___ 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: Xcode 5 Obj-C++
How did you factor out the application logic from the UI rendering? On 30 Jan 2014, at 21:16, Jo Meder jome...@ihug.co.nz wrote: Hi, Language philosophy aside, our application is a largish cross platform (Mac, Windows, Linux) application written in C++. The UI framework uses Cocoa for the Mac back end, which means we're using Objective-C++ to interface with Cocoa. I've recently, at long last, been able to upgrade from Xcode 3 to Xcode 5. I had to make very few changes to the Objective-C++ code to get it to work. In fact it was so minor I've forgotten what it was exactly, something to do with the way I was making forward declarations of some Objective-C objects in headers that were shared by C++ and Objective-C++ code IIRC. Anyway, it wasn't any big drama. All my work was based on the various Objective-C++ resources available in late 2010, which was when I ported the UI framework to Cocoa from Carbon. There are some newer language features such as ARC which I'm not using, so I don't know what effect that might have. Essentially though, Xcode 5 and Objective-C++ are no problem. Regards, Jo Meder ___ 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/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Xcode 5 Obj-C++
On 2014-01-30, at 3:16 PM, Jo Meder jome...@ihug.co.nz wrote: Hi, Language philosophy aside, our application is a largish cross platform (Mac, Windows, Linux) application written in C++. The UI framework uses Cocoa for the Mac back end, which means we're using Objective-C++ to interface with Cocoa. I've recently, at long last, been able to upgrade from Xcode 3 to Xcode 5. I had to make very few changes to the Objective-C++ code to get it to work. In fact it was so minor I've forgotten what it was exactly, something to do with the way I was making forward declarations of some Objective-C objects in headers that were shared by C++ and Objective-C++ code IIRC. Anyway, it wasn't any big drama. All my work was based on the various Objective-C++ resources available in late 2010, which was when I ported the UI framework to Cocoa from Carbon. There are some newer language features such as ARC which I'm not using, so I don't know what effect that might have. Essentially though, Xcode 5 and Objective-C++ are no problem. Regards, Jo Meder That's a good and useful reply to address my concerns. Thanks… Peter ___ 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: Xcode 5 Obj-C++
On 2014-01-30, at 3:23 PM, Rui Pacheco rui.pach...@gmail.com wrote: How did you factor out the application logic from the UI rendering? On 30 Jan 2014, at 21:16, Jo Meder jome...@ihug.co.nz wrote: Hi, Language philosophy aside, our application is a largish cross platform (Mac, Windows, Linux) application written in C++. The UI framework uses Cocoa for the Mac back end, which means we're using Objective-C++ to interface with Cocoa. I've recently, at long last, been able to upgrade from Xcode 3 to Xcode 5. I had to make very few changes to the Objective-C++ code to get it to work. In fact it was so minor I've forgotten what it was exactly, something to do with the way I was making forward declarations of some Objective-C objects in headers that were shared by C++ and Objective-C++ code IIRC. Anyway, it wasn't any big drama. All my work was based on the various Objective-C++ resources available in late 2010, which was when I ported the UI framework to Cocoa from Carbon. There are some newer language features such as ARC which I'm not using, so I don't know what effect that might have. Essentially though, Xcode 5 and Objective-C++ are no problem. Regards, Jo Meder I don't know how Jo did it but in my case the model will (most likely need to) be C++ and the UI (which is merely for interim progress reporting and debugging) will be Obj-C, mainly Cocoa. The main process does not need a GUI. Last time I seriously used Obj-C++ was back in the Xcode 3 days so just wanted to find out what has changed. Jo's answer is most comforting. Peter ___ 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: Xcode 5 Obj-C++
Hi Rui, On 31/01/2014, at 9:23 AM, Rui Pacheco wrote: How did you factor out the application logic from the UI rendering? If you mean our application logic, it essentially comes down to abstraction. The application is C++ and sits on our application framework, similar to Qt or wxWidgets. The application framework is also mostly C++ and it mainly uses a bridge pattern to interface with platform specific back ends. On the Mac this back end is Cocoa (Obj-C++), on Windows it's Win32 and on Linux the UI specific parts are empty as the app runs as a CLI render node. The application itself has no knowledge of the underlying API. Well, that's not entirely true as the framework is designed to be thin so the application can get to platform specific stuff if need be, but that's the idea anyway. All UI elements are created programatically, so we don't use nibs on the Mac. In fact I do use IB to design the Mac interface when needed but I have a tool which generates an XML file from the nib, and the XML file is parsed by the framework to generate the UI. It's a bit old school but I use IB 3 and a Carbon nib for this, as that is sufficient for my needs. It does mean I have to do some tweaking to account for layout differences at times. Regards, Jo Meder ___ 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: Xcode 5 Obj-C++
On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. Exactly. Also, the use of templates or inline methods in library classes will cause library code to get built into the calling app at compile time. After that, the library has to be very careful not to break compatibility with such code to avoid breaking the app. A typical obvious example is changing the implementation of an inline method; newly compiled apps will get the new behavior but existing apps will keep the old behavior since the inlined code is in the app not the library. That's bad news if the old inline method accesses private state of the old version of the class that no longer exists in the same form in the new version. It is possible to create binary-compatible C++ APIs but you have to be very, very careful — generally there are a lot of rules about the use of inlines and templates; you have to add placeholder data members and virtual methods to classes to reserve room for future expansion, etc. —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: Xcode 5 Obj-C++
Is this documented somewhere? On 30 Jan 2014, at 22:26, Jens Alfke j...@mooseyard.com wrote: On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. Exactly. Also, the use of templates or inline methods in library classes will cause library code to get built into the calling app at compile time. After that, the library has to be very careful not to break compatibility with such code to avoid breaking the app. A typical obvious example is changing the implementation of an inline method; newly compiled apps will get the new behavior but existing apps will keep the old behavior since the inlined code is in the app not the library. That's bad news if the old inline method accesses private state of the old version of the class that no longer exists in the same form in the new version. It is possible to create binary-compatible C++ APIs but you have to be very, very careful — generally there are a lot of rules about the use of inlines and templates; you have to add placeholder data members and virtual methods to classes to reserve room for future expansion, etc. —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/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Xcode 5 Obj-C++
On Jan 30, 2014, at 1:38 PM, Peter Teeson ptee...@icloud.com wrote: ...so just wanted to find out what has changed. Support for most of C++11 :-) :-) :-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Xcode 5 Obj-C++
Google Taligent. (Snicker, snicker, snicker...) They actually wrote a good book on the subject, which was very effective at convincing most sane people to JUST NOT EVEN TRY THAT ;-) Anyway, this has *nothing* to do with Cocoa, OS X, iOS or Xcode. It's just C++, and such things are covered to varying extents in many many C++ books. On Jan 30, 2014, at 2:35 PM, Rui Pacheco rui.pach...@gmail.com wrote: Is this documented somewhere? On 30 Jan 2014, at 22:26, Jens Alfke j...@mooseyard.com wrote: On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. Exactly. Also, the use of templates or inline methods in library classes will cause library code to get built into the calling app at compile time. After that, the library has to be very careful not to break compatibility with such code to avoid breaking the app. A typical obvious example is changing the implementation of an inline method; newly compiled apps will get the new behavior but existing apps will keep the old behavior since the inlined code is in the app not the library. That's bad news if the old inline method accesses private state of the old version of the class that no longer exists in the same form in the new version. It is possible to create binary-compatible C++ APIs but you have to be very, very careful — generally there are a lot of rules about the use of inlines and templates; you have to add placeholder data members and virtual methods to classes to reserve room for future expansion, etc. —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/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.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/scott_ribe%40elevated-dev.com This email sent to scott_r...@elevated-dev.com -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Xcode 5 Obj-C++
On Jan 30, 2014, at 1:35 PM, Rui Pacheco rui.pach...@gmail.com wrote: Is this documented somewhere? These are well-known problems but I don't know if there's authoritative documentation. (And C++ partisans would tell you that many of these things are limitations of the usual C++ runtimes, not the language itself, but I'm not aware of any current runtimes that avoid them.) Some good places to start reading: http://en.wikipedia.org/wiki/Fragile_binary_interface_problem http://en.wikipedia.org/wiki/Fragile_base_class Web searches for [fragile base class] will turn up zillions of other documents. —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: Xcode 5 Obj-C++
On 1/30/14, Jens Alfke j...@mooseyard.com wrote: On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: It is barely possible to create a stable ABI in C++. This language suffers all possible form of fragile base class problem: Add a new ivar, all subclasses and stack allocated objects are broken. Add a new virtual method, you break all virtual subclasses. Exactly. Also, the use of templates or inline methods in library classes will cause library code to get built into the calling app at compile time. After that, the library has to be very careful not to break compatibility with such code to avoid breaking the app. A typical obvious example is changing the implementation of an inline method; newly compiled apps will get the new behavior but existing apps will keep the old behavior since the inlined code is in the app not the library. That's bad news if the old inline method accesses private state of the old version of the class that no longer exists in the same form in the new version. It is possible to create binary-compatible C++ APIs but you have to be very, very careful -- generally there are a lot of rules about the use of inlines and templates; you have to add placeholder data members and virtual methods to classes to reserve room for future expansion, etc. --Jens And there's more... The compilers can do name mangling differently, so if you switch compilers or change the version of the same compiler, there is a chance that the binaries won't be compatible. And to re-iterate on what Jens just said, this kind of problem gets intertwined with the C++ standard library. This generally means you can't mix standard libraries and potentially different versions of the same standard library. Android is one of the best (worst?) examples of this. Android makes developers choose from 3-4 different compiler versions (multiple versions of gcc and clang), and then also makes you pick which C++ standard library you want to use (a minimal Android one, STLport, GNU, and potentially the new clang one). All of these are incompatible so you can't mix and match. 4x4 means you have 16 ways you can blow up your code. Static linking and only exposing extern C APIs can help in some cases, but more often than not, I've dealt with people/libraries/SDKs who don't understand this (but really need to) and they are not doing this which has forced me to work around all sorts of bad situations. And I've already encountered people who've run into the same problem on Mac/iOS with libstdc++ and libc++ because they didn't understand this. I've been fortunate that most of the stuff I've dealt with doesn't use C++ exceptions because I think that is another headache area. As for rules, I don't know any centralized place. The problem is that C++ is so complex and ABI stability is not a goal. In addition, some rules/behaviors are not obvious on how things will be impacted. One example issue that caught both me and Apple off-guard was during the 10.5 time frame, Apple redefined GLenum trying to get stuff 64-bit ready. Under 32-bit, the GLenum type was changed from long (in 10.4 and before) to int (in 10.5). Under 32-bit, sizeof(long) == sizeof(int) == 4-bytes. (In 64-bit, sizeof(long) == 8-bytes, sizeof(int) == 4-bytes) So in C 32-bit, binary compatibility is preserved and this is perfectly fine to do which is why the change was okayed. But under C++, even though both types are 4-bytes under 32-bits, the gcc/C++ name mangling treat int and long as fundamentally different types. Thus binary compatibility is broken if you try linking two pieces of code that use different types for GLenum. I suppose this is technically up to the compiler and its chosen name mangling, but the end result is that this made it impossible to ship a C++ framework binary that worked on both 10.4 and 10.5. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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: Xcode 5 Obj-C++
On Jan 30, 2014, at 2:14 PM, Jens Alfke j...@mooseyard.com wrote: And C++ partisans would tell you that many of these things are limitations of the usual C++ runtimes, not the language itself, but I'm not aware of any current runtimes that avoid them. I bet those same partisans would be the first to the barricades to complain about the performance downsides of any C++ runtime implementation that did try to improve ABI fragility. -- 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
Xcode 5 Obj-C++
I have a project in which I want to take advantage of the C++ Standard library (primarily because of the container classes - including the special ones). FWIW the project has to traverse a directed acyclic graph (yes I know about the boost lib). For the rest of the project Obj-C and Cocoa is sufficient. All the searching I've done has not turned up anything current about how things work these days with Xcode 5 and llvm. There is the 2005 ObjC++.pdf which I have but Xcode has changed a lot since those days. I understand that the file extension needs to be .mm to mix Obj-C and C++. But other than a command line template, which is for C++, there does not seem to be one for ObjC++. Are there any current docs that my search didn't find and that you can point me to? Or advice you can offer to help me? TIA and respect…. Peter ___ 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: Xcode 5 Obj-C++
Peter, On Jan 29, 2014, at 12:02 PM, Peter Teeson ptee...@icloud.commailto:ptee...@icloud.com wrote: I have a project in which I want to take advantage of the C++ Standard library (primarily because of the container classes - including the special ones). FWIW the project has to traverse a directed acyclic graph (yes I know about the boost lib). For the rest of the project Obj-C and Cocoa is sufficient. All the searching I've done has not turned up anything current about how things work these days with Xcode 5 and llvm. There is the 2005 ObjC++.pdf which I have but Xcode has changed a lot since those days. I understand that the file extension needs to be .mm to mix Obj-C and C++. But other than a command line template, which is for C++, there does not seem to be one for ObjC++. There are several ways you can do this, I mention two here: 1- As you mentioned, change the file extension to .mm 2- In your build setting (depending on configuration) you will see either of the two below GCC_INPUT_FILETYPE Compile Sources As You can change this setting to compile all your files as Objective-C++, regardless of the file extension. Are there any current docs that my search didn't find and that you can point me to? Or advice you can offer to help me? Well, I’m not clear as to what information you’re trying to find. Can you elaborate? Thanks, Abdul TIA and respect…. Peter ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.commailto: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.comhttp://lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/asowayan%40vectorworks.net This email sent to asowa...@vectorworks.net ___ 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: Xcode 5 Obj-C++
On Jan 29, 2014, at 10:02 AM, Peter Teeson ptee...@icloud.com wrote: But other than a command line template, which is for C++, there does not seem to be one for ObjC++. Yep. Never has been. Are there any current docs that my search didn't find and that you can point me to? Or advice you can offer to help me? Just dive in. It's not hard. Unfortunately, I haven't done this from scratch since Xcode 2, so I can't tell you exactly what to do but... Name a file .mm. Include some C++ headers. Write some C++ code. See how far you get ;-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Xcode 5 Obj-C++
On Jan 29, 2014, at 9:02 AM, Peter Teeson ptee...@icloud.com wrote: I understand that the file extension needs to be .mm to mix Obj-C and C++. But other than a command line template, which is for C++, there does not seem to be one for ObjC++. It's honestly not any different. You're writing Objective-C code but you can use all of the extensions that C++ adds. (Or alternatively, you're writing C++ code but you can use Objective-C types and message objects. It depends on your use case.) So for example you have an Objective-C class that wants to use std::vector. Cool, just add #include vector, then use std::vector wherever you want. Just avoid using C++ syntax or types in the class header, otherwise you won't be able to #import it from any non-Obj-C++ source files. (Or alternatively you could just make all of your source files use Obj-C++.) —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: Xcode 5 Obj-C++
On Jan 29, 2014, at 1:48 PM, Jens Alfke j...@mooseyard.com wrote: On Jan 29, 2014, at 9:02 AM, Peter Teeson ptee...@icloud.com wrote: I understand that the file extension needs to be .mm to mix Obj-C and C++. But other than a command line template, which is for C++, there does not seem to be one for ObjC++. All my projects are Obj-C and C++ mixed so rather than change any file extension I just set in the Language section of Build Setting Compile Sources As Objective-C++ -koko ___ 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: Xcode 5 Obj-C++
On 29 Jan 2014, at 18:02, Peter Teeson ptee...@icloud.com wrote: All the searching I've done has not turned up anything current about how things work these days with Xcode 5 and llvm. There is the 2005 ObjC++.pdf which I have but Xcode has changed a lot since those days. I talked about ObjC++ on NSBrief a while ago: http://nsbrief.com/113-uli-kusterer/ It’s a very comprehensive summary of all the tricks and techniques I commonly use, plus an introduction into how the whole thing behaves. I understand that the file extension needs to be .mm to mix Obj-C and C++. But other than a command line template, which is for C++, there does not seem to be one for ObjC++. It’s not needed. You can just add .mm files to a project created from the ObjC++ template and it’ll work. IIRC you don’t even have to add the -lc++ option to add the C++ standard library anymore. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: Xcode 5 Obj-C++
To those of you doing Objective-C++ apps, is there a difference in terms of performance or memory usage? I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less memory than the Chocolat editor which seems to be done exclusively in Cocoa. On 30 Jan 2014, at 00:04, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 29 Jan 2014, at 18:02, Peter Teeson ptee...@icloud.com wrote: All the searching I've done has not turned up anything current about how things work these days with Xcode 5 and llvm. There is the 2005 ObjC++.pdf which I have but Xcode has changed a lot since those days. I talked about ObjC++ on NSBrief a while ago: http://nsbrief.com/113-uli-kusterer/ It’s a very comprehensive summary of all the tricks and techniques I commonly use, plus an introduction into how the whole thing behaves. I understand that the file extension needs to be .mm to mix Obj-C and C++. But other than a command line template, which is for C++, there does not seem to be one for ObjC++. It’s not needed. You can just add .mm files to a project created from the ObjC++ template and it’ll work. IIRC you don’t even have to add the -lc++ option to add the C++ standard library anymore. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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/rui.pacheco%40gmail.com This email sent to rui.pach...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Xcode 5 Obj-C++
On Jan 29, 2014, at 3:16 PM, Rui Pacheco rui.pach...@gmail.com wrote: To those of you doing Objective-C++ apps, is there a difference in terms of performance or memory usage? I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less memory than the Chocolat editor which seems to be done exclusively in Cocoa. You can't generalize. In theory C++ is more efficient, but it's perfectly possible to write bloated code in C++ and plenty of people have done it. (In particular, big class libraries can result in humungous vtables, and templates and inlining can cause code-size explosions.) It's also all too easy to write unmaintainable code in C++, and that's often an even more important factor to a developer than performance. Objective-C is simpler, but it's also clearer. —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: Xcode 5 Obj-C++
On 30 Jan 2014, at 00:16, Rui Pacheco rui.pach...@gmail.com wrote: To those of you doing Objective-C++ apps, is there a difference in terms of performance or memory usage? I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less memory than the Chocolat editor which seems to be done exclusively in Cocoa. Give the nature of C++, it’s not surprising that performance can often be better. They generally tend to put a higher emphasis on performance than on programmer comfort, maintainability etc. Also, C++ can do a lot of mean tricks due to the more static nature of the language. E.g. their method dispatch is not easy to keep binary stable across releases, so is really badly suited for API design in dylibs or frameworks, but probably only needs two pointer dereferences and one addition to resolve a method, while ObjC actually has to perform the look-up at runtime, but therefore works much better as a library API. I don’t usually have to drop down to C++ unless: 1) I’m in very performance-critical code, like device drivers, video decoders etc. 2) I need my code to be cross-platform, because C++ is really the most reliably available OO-language everywhere from Android to Windows to iOS. Unless you’re in one of those situations, I wouldn’t drop down to C++ just because it “is probably faster”. It helps nobody if your app crashes faster because all that code you rewrote that you’d get for free in ObjC or C# or the ADK is buggy. The more people use a piece of code, the more likely it is one of them found a bug got it fixed. Tested code is always better than new, “fast” code. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: Xcode 5 Obj-C++
On Jan 29, 2014, at 6:41 PM, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 30 Jan 2014, at 00:16, Rui Pacheco rui.pach...@gmail.com wrote: To those of you doing Objective-C++ apps, is there a difference in terms of performance or memory usage? I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less memory than the Chocolat editor which seems to be done exclusively in Cocoa. Give the nature of C++, it’s not surprising that performance can often be better. They generally tend to put a higher emphasis on performance than on programmer comfort, maintainability etc. Also, C++ can do a lot of mean tricks due to the more static nature of the language. E.g. their method dispatch is not easy to keep binary stable across releases, so is really badly suited for API design in dylibs or frameworks, but probably only needs two pointer dereferences and one addition to resolve a method, while ObjC actually has to perform the look-up at runtime, but therefore works much better as a library API. I don’t usually have to drop down to C++ unless: 1) I’m in very performance-critical code, like device drivers, video decoders etc. 2) I need my code to be cross-platform, because C++ is really the most reliably available OO-language everywhere from Android to Windows to iOS. Unless you’re in one of those situations, I wouldn’t drop down to C++ just because it “is probably faster”. It helps nobody if your app crashes faster because all that code you rewrote that you’d get for free in ObjC or C# or the ADK is buggy. The more people use a piece of code, the more likely it is one of them found a bug got it fixed. Tested code is always better than new, “fast” code. Unfortunately, sometimes you have to use C++, because there are many cool and useful libraries for it, as I’m sure most of you know. Many people (but not all) use C++ not because they want to or think it’s “fast”, but because they have to to leverage an existing library or codebase. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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/sevenbitstech%40gmail.com This email sent to sevenbitst...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Xcode 5 Obj-C++
On 1/29/14, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 30 Jan 2014, at 00:16, Rui Pacheco rui.pach...@gmail.com wrote: To those of you doing Objective-C++ apps, is there a difference in terms of performance or memory usage? I've noticed that TextMate 2, which is done in Objective-C++, consumes less memory than the Chocolat editor which seems to be done exclusively in Cocoa. Give the nature of C++, it's not surprising that performance can often be better. They generally tend to put a higher emphasis on performance than on programmer comfort, maintainability etc. Also, C++ can do a lot of mean tricks due to the more static nature of the language. E.g. their method dispatch is not easy to keep binary stable across releases, so is really badly suited for API design in dylibs or frameworks, but probably only needs two pointer dereferences and one addition to resolve a method, while ObjC actually has to perform the look-up at runtime, but therefore works much better as a library API. I don't usually have to drop down to C++ unless: 1) I'm in very performance-critical code, like device drivers, video decoders etc. 2) I need my code to be cross-platform, because C++ is really the most reliably available OO-language everywhere from Android to Windows to iOS. Unless you're in one of those situations, I wouldn't drop down to C++ just because it is probably faster. It helps nobody if your app crashes faster because all that code you rewrote that you'd get for free in ObjC or C# or the ADK is buggy. The more people use a piece of code, the more likely it is one of them found a bug got it fixed. Tested code is always better than new, fast code. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://zathras.de - Additionally, C++ will typically increase your compile and link times. - Binary compatibility (already mentioned) is a pain, so libraries need to be extremely careful. Additionally, use of templates often leads to lots more symbols and larger binary size (dynamic libraries can't really be stripped for unused symbols). - Often when comparing Obj-C vs. C++, method dispatch is one of the main culprits for the performance difference. But don't forget, Obj-C is a pure superset of C and you can always use good old C to get the same performance benefits if you don't need/want the Obj-C features. Other really high performance situations deal with cache and memory layout and it turns out that much of the C++ standard library is not well suited for dealing with this and going back to POD types and essentially C (if not assembly) is often better for performance. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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: Xcode 5 Obj-C++
On Jan 29, 2014, at 4:28 PM, Eric Wing ewmail...@gmail.com wrote: - Additionally, C++ will typically increase your compile and link times. Oh my yes. The C++ compiler generates huge amounts of symbolic data and nearly chokes the linker. The last big C++ project I worked on (Chrome) took over a minute just to link, which meant the turnaround was at least that long if I made a one-line change. By creating a RAM disk(!) to store the build output I was able to speed that up to 30 sec, which was painful but better. - Binary compatibility (already mentioned) is a pain, so libraries need to be extremely careful. Anyone exposing a C++ API in a dynamic library is nuts, IMHO. Apple did so with IOKit and I'm sure they've regretted it ever since. - Often when comparing Obj-C vs. C++, method dispatch is one of the main culprits for the performance difference. That's one of them. The other major one is the way that Obj-C has to allocate all* objects on the heap, whereas in C++ you can allocate small temporary objects on the stack, or embed them in other objects. Part of knowing how to use Obj-C effectively is knowing when _not_ to make something an object. If there will be zillions of tiny instances, or if it has to be called in ultra performance sensitive code, it's better to drop down to C or C++ for just that specific task. —Jens * except for a subset of NSNumbers which the runtime cleverly hides inside tagged pointers, a C++-like trick ___ 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: Xcode 5 Obj-C++
On Jan 29, 2014, at 4:42 PM, Jens Alfke wrote: * except for a subset of NSNumbers which the runtime cleverly hides inside tagged pointers, a C++-like trick Smalltalk did it first. ___ 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: Xcode 5 Obj-C++
On Jan 29, 2014, at 4:57 PM, Lee Ann Rucker lruc...@vmware.com wrote: On Jan 29, 2014, at 4:42 PM, Jens Alfke wrote: * except for a subset of NSNumbers which the runtime cleverly hides inside tagged pointers, a C++-like trick Smalltalk did it first. Lisp probably did it before that. -- 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: Xcode 5 Obj-C++
On Jan 29, 2014, at 4:57 PM, Lee Ann Rucker lruc...@vmware.com wrote: Smalltalk did it first. Actually LISP did it first, if you want to get pedantic… (Wikipedia has let me down: the entry for Tagged Pointer is pretty lame and has no discussion of the history.) —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: Xcode 5 Obj-C++
On 30 Jan 2014, at 12:02 pm, Jens Alfke j...@mooseyard.com wrote: Wikipedia has let me down: the entry for anything you know something about is pretty lame FTFY ;) --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: Xcode 5 Obj-C++
On Jan 29, 2014, at 6:02 PM, Greg Parker gpar...@apple.com wrote: Lisp probably did it before that. Hell, Lisp machines did it in hardware ;-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
