macOS C++ interface to Cocoa?

[Bobbyski]

Bobbyski, not sure if this will be of any interest or use to you, but have you seen this.

b e n

I am familiar with this project as well as the wxWidgets and cplat which are more mature and provide cross-platform usability.

The advantages to a Cocoa wrapper library are in having all of Apple's controls available in short order after they are introduced and that the controls would be native, not approximations. Each of these libraries produce Mac software that looks very mac like but they lack the elegance and sophistication of Cocoa Applications. Look at Apple's applications as well as Omni's and Delicious Monster's, they all are in a class above and share the common trait of being very Cocoa centric.

Perhaps it is time to just accept it and go fully objective-C.

 

[lazydog]

Perhaps you are right! But, like you, I would find it very difficult to give up C++ completely in favor of Objective-C. Putting Cocoa aside for one moment, there's so much going for C++. For example, there was a thread not so long ago about the poor performance of NSSet. As a test I ran the same experiment but using std::set and the difference in performance was dramatic. So it's hard not take advantage of all the well written libraries that you get for free with C++. But, programming in Objective-C++ is a bit like living half way between two places. So I can understant your predicament. By the way the link I was thinking of was the Nano project. Not looked at it really, just saw it in passing some time ago.

b e n

 

[Bobbyski]

Any progress

Well, I guess it would take a long time to write C++ wrappers, but still I'm surprised there isn't an open source version around so that cross platform code could be more Mac like.

(please someone correct me if I'm wrong before I think too much into this... )

Have you made any progress? I am interested in a C++ library that thinly wrapped Cocoa. I would be willing to help if the open source license is acceptable (BSD or MIT).

 

[Sander]

TBUT I have to know what it is about C++ that potential users would want to see. Is it STRICTLY syntax? Or is it also some semantics: objects allocated on the stack, templates, multiple inheritance, etc.?

One word: RAII!

 

[gnasher729]

For example, there was a thread not so long ago about the poor performance of NSSet. As a test I ran the same experiment but using std::set and the difference in performance was dramatic.

Two things to say about that: NSSet is based on hash tables. Its performance is extremely good, unless you use objects with a bad hash function. NSSet unfortunately has a bad hash function itself. So the only case were NSSet is slow is exactly the performance test that was discussed: Stuffing 65536 NSSet objects into an NSSet. However, that particular test was meaningless as a real-world test. If you wanted to create a set of subsets of a given set, you would just use a bit array which beats an std::set implementation easily by a factor hundred.

In normal applications (sets of arbitrary objects, sets of numbers, sets of strings etc.) NSSet operates in constant time: Time to add an element to an NSSet or time to check if an object is in an NSSet is O (1). std::set, on the other hand, doesn't use hashing but only comparisons and therefore takes logarithmic time, O (ln N); substantially slower. It also forces you to do stupid thinks like creating a compare function that will check whether say one window is "less than" another window when you create a set of windows.

So in real-life situations, I would seriously doubt that std::set is ever the best possible implementation.

 

[bobrik]

Qt Cocoa

If so... is this probably the way that REALbasic will be using for its up and coming Cocoa version? And... why don't others follow along with this instead of sticking with Carbon (e.g. Qt).

Cocoa port of Qt reached alpha 2 status, they started working in order to support cross-platform 64-bit coding right after Apple announced last WWDC that Carbon will not be 64-bit (unlike Cocoa which is now 32-bit and 64-bit).

Have a look here: http://labs.trolltech.com/blogs/2008/06/09/second-cocoa-alpha-released/

Though apart from 64-bit support, remember that it will not make any difference to you (which is good - one code, more platforms ;-)), since you still use the very same Qt APIs as anywhere else. But it can serve as a "proof of concept" that making C++ abstraction framework around Obj-C framework is possible.

 

[lazydog]

Two things to say about that: NSSet is based on hash tables. Its performance is extremely good, unless you use objects with a bad hash function. NSSet unfortunately has a bad hash function itself. So the only case were NSSet is slow is exactly the performance test that was discussed: Stuffing 65536 NSSet objects into an NSSet. However, that particular test was meaningless as a real-world test. If you wanted to create a set of subsets of a given set, you would just use a bit array which beats an std::set implementation easily by a factor hundred.

In normal applications (sets of arbitrary objects, sets of numbers, sets of strings etc.) NSSet operates in constant time: Time to add an element to an NSSet or time to check if an object is in an NSSet is O (1). std::set, on the other hand, doesn't use hashing but only comparisons and therefore takes logarithmic time, O (ln N); substantially slower. It also forces you to do stupid thinks like creating a compare function that will check whether say one window is "less than" another window when you create a set of windows.

So in real-life situations, I would seriously doubt that std::set is ever the best possible implementation.

Hi

I see what you're saying, though I thought implementations of std::set use balanced trees, so depending on your data they can work in log time too. For ad hoc small sets like your set of window (pointers) the default comparison < would likely be fine.

The set of subsets might have been a specific example better coded as you suggested, but the general case of a set of sets (not an uncommon situation to have to code) would perform better I think using std::set than NSSet even when using the default < comparison function.

By the way I wasn't trying to start an NSSet v std::set argument, I don't really know enough to do that! Just trying to say that I think Objective-C++ gives you more scope and flexibility than straight Objective-C.

b e n

 

[CPlusPlusMan]

One should be written

I've seen this argument all over. how C++ isn't a "real" OO Language. I hear about how it doesn't have certain features, or how it's poorly designed... the FQA is a frequent reply to my insistence that C++ is indeed a good language for OO programming. But I as a programmer (I've been writing code since I was 12) I want to go on record and say a few things:

1: Why would you array a set of objects that have nothing in common typewise? This to me is a very poor design and the lack of type checking is disturbing... this language must be hell to debug. arrays are for collecting a group of similar objects together for quick access in an incremental list. Consider the following:

Given that C is an array, what is it an array of.... if you say, it's an array of a bunch of things then that begs the question: well, why are they together? why didn't you group them in a structure, why did you make an array out of them? I can think of no useful, scalable, understandable design that would require a single array that can contain a multitude of types. there's simply no reason for the feature.

2: Objective C is a hodgepodge! I don't know what any programmer sees in it, it's like the girl who likes the deadbeat guy and the C++ programmers are trying to tell these girls that that guy isn't right for them that he sucks but they won't listen and instead bring up the C++ programmer's personal weaknesses. I've yet to hear any compelling reason (except that cocoa tries to force you to be able to program it) to abandon all my C++ knowledge, limit it to standard C, and the God aweful smalltalk extensions. ironically the highly inferior code of old old K and R C being compatable is considered a primary advantage of Obj-C over C++.... there's a reason that code doesn't work in C++... it's so poorly written that it fails to be efficient or scalable at least in one way and most likely in many others. If you don't think it's a hodgepodge, then consider the following:

@interface
@implementation
@public
@private
@protected
@class
@end

..... now, I'm no expert on C programming.... but have you ever seen straight C code that uses these conventions?... ever seen straight C keywords that begin with @?.... I've yet to find a program in straight C that does. now it's one thing if it's a seperate aspect.... like for example... the preprocessor code all begins with #. this is to denote that this code is processed by the preprocessor and not compiled code, it provides a useful and logical seperation..... @ is there because that's the way the designer made it, and because it is showing the OO portions of the program.... but why? there's no reason for the keywords to be different, you're still creating compiled code there... it's not like the preprocessor, that code will turn into an executable, it's not just an abstraction... next there's this:

[Object Message : Parameters];

Now, what is a message essentially? it's basically a function that belongs to an object because it's of whatever type or class contains it. so why does it look completely different than a function in terms of syntax... shouldn't some of the syntax be retained?
how about Object->Message (parameters); just like a C struct... or if it's not a pointer, then Object.Message (parameters);..... oh wait, that looks exactly like a part of C.... and guess what.... it is! but Objective C refuses to be an internally consistent language and act like that... even if you changed the symbols for accessing members and methods of an object: Object+>Method (params); for Object, and Object->Method (params); for factory methods. or if you want to make it easier so the programmer doesn't have to know those details: Object.Method (params); for concrete objects, and Object->Method (params); for pointers to objects. still not convinced?

+(void) FunctionName : (Type) Param1, (MyType) Param2;
- (void) MyOtherFunction : (Type) Param;

Again.... are these functions or are we just borrowing the syntax from another language to add more complexity and make the language look like something new when all we're doing is forcing the programmer to learn more syntax? I think it's the latter. why are the types in parenthesis? couldn't we just declare them like normal C functions inside the braces of a class or type? which brings up another point? what is it with the variables being within curly braces, but the function has to be after the brace but before the @end keyword? that is quite nonsensical, it makes it look like the functions are separate. a class most closely resembles a C struct. so why not make it look like a C struct? except you use a different keyword? and also, why is it that you have to make a block contain the interface and another block the implementation? why can't you just implement it using some sort of scoping operator? in the end the advantages of doing that is that it looks like .... oh wait! C!!!!!! instead of a hodgepodge of C and Smalltalk and Esperanto.

So what now? I think a wrapper library needs to be written.... at least a wrapper library, if not a set of bindings for obj c. Or cocoa needs to be hacked and reimplemented in C++. I've yet to hear a valid argument against C++ that stood up to scrutiny. the worst is that C++ compiles slower to accomodate for code ambiguities that depend on context. that's great! C++ isn't perfect but it doesn't have to be. Obj-C has much worse flaws than it's inconsistent syntax and the few groupies among the programmers who insist that we're ignorant or retarded because we strongly dislike the language. yes, the programmers who see C++ programmers as inferior because they're not real OO programmers (btw, any computer scientist who's more than a code monkey knows that OO is valuable sometimes but not all the time and that safety needs to exist to protect the program from breaking the system) obviously don't understand C++ and why it is designed the way it is. I'm probably more surprised that the people who like it do so, than the people who do like it that I hate it. As I've mentioned before, I've seen no compelling reason (cocoa is a good library but it's still inferior in my opinion to Qt) to convert to obj-C except to wrap it in C++ just so I can write programs in my preferred pet programming language.

I'm sorry that post is long but that's how I feel about the whole issue.
Gino

 

[Krevnik]

I've seen this argument all over. how C++ isn't a "real" OO Language. I hear about how it doesn't have certain features, or how it's poorly designed... the FQA is a frequent reply to my insistence that C++ is indeed a good language for OO programming. But I as a programmer (I've been writing code since I was 12) I want to go on record and say a few things:

Yes, C++ is a real OO language. It isn't dynamically typed though. That makes some things possible in a dynamically typed language harder to do in C++. Cocoa/AppKit takes advantage of informal protocols and other aspects of Objective-C which are harder to implement in C++ (not impossible, just harder).

1: why the hell would anyone want to create an array that consisted of a set of completely different objects? I mean that has to be the most piss poor technique I've ever seen. arrays are for collecting a group of similar objects together for quick access in an incremental list. Consider the following:

Given that C is an array, what is it an array of.... if you say, it's an array of a bunch of things then that begs the question: well, why are they together? why didn't you group them in a structure, why did you make an array out of them? I can think of no useful, scalable, understandable design that would require a single array that can contain a multitude of types. there's simply no reason for the feature.

Formal or informal protocols can be a way to group objects together in a way that makes sense. In a strongly typed language, informal protocols don't exist. Formal protocols have to be handled as abstract or virtual types, but can still be used in templates.

In Objective-C, grouping objects that follow an informal protocol is more interesting. And really, using an NSArray of NSObjects makes more sense in Objective-C, where you don't even have a concept of templates. You can't have a write-once, use-everywhere generic collection without either templates (C++) or using a single base type (Objective-C / Cocoa). I can think of a couple times where I used a collection of objects that were grouped because of their informal protocol, rather than their type.

2: Objective C is a hodgepodge! I don't know what any programmer sees in it, it's like the girl who likes the deadbeat guy and the C++ programmers are trying to tell these girls that that guy isn't right for them that he sucks but they won't listen and instead bring up the C++ programmer's personal weaknesses. I've yet to hear any compelling reason (except that cocoa tries to force you to be able to program it) to abandon all my C++ knowledge, limit it to standard C, and the God aweful smalltalk extensions. ironically the pisspoor code of old old K and R C being compatable is considered a primary advantage of Obj-C over C++.... there's a reason that code doesn't work in C++... it's so poorly written that it sucks at least in one way and most likely in many others. If you don't think it's a hodgepodge, then consider the following: <snipped for sanity>

A couple things to mention:

- A message may syntactically seem like an object method, but it behaves in a way that isn't always intuitive. It really winds up doing a vtable dispatch based on the object, and dispatches it if possible, otherwise it throws an exception. C/C++ doesn't allow this sort of ad-hoc resolving of symbols, C/C++ requires a function pass muster at compiletime, not runtime.

- Objective-C was designed at a time before the concept of what makes a language stabilized into "it should be C". Back in the era where a language simply was what the designer(s) felt was best for it.

So yes, Objective-C is a hodgepodge, and maybe not the ideal in terms of syntax. That isn't to say C is ideal either, but I am not going to disagree that Objective-C feels like a second language slapped onto a first.

So what now? I think a wrapper library needs to be written.... at least a wrapper library, if not a set of bindings for obj c.

Because of the differences in how things get typed in C++ versus Obj-C, bindings will be tricky. A wrapper library should be possible, but it would be expensive to maintain outside of Apple doing it themselves.

Or cocoa needs to be hacked and reimplemented in C++. I've yet to hear a valid argument against C++ that stood up to scrutiny. the worst is that C++ compiles slower to accomodate for code ambiguities that depend on context. that's great! C++ isn't perfect but it doesn't have to be.

There are some things that Apple currently relies on in the core of AppKit that requires a dynamically typed language. While it would be possible to port most of this to C++, it would be a big effort. Cocoa came into being because it already existed on NeXTStep, not because it was new. Apple wanted a more modern API in OS X, and they had this mostly-complete API in the form of the NeXTStep APIs. It allowed Apple to push a modernized API set to their new platform faster than it would have been otherwise.

They just haven't been willing to spend the manpower required to port the whole API set over. And if they had decided to continue to maintain Carbon for 64-bit, that was supposed to be their C/C++ API for developers, rather than Cocoa (using CoreServices as a shared C foundation that both built up on).

And I will say that I have chunks of code that would not work without major restructuring in C++. Of course, I have code which abuses Objective-C specific functionality (like introspection, and KVC is a great little piece of tech to play with), which is why it doesn't port easily.

And really, my only argument against a C++ version of Cocoa? It wouldn't be Cocoa. It would be like Cocoa, but it wouldn't be Cocoa. A fair number of the Obj-C oriented technologies don't make sense in a statically typed language, and would behave and be implemented differently. Although big chunks would remain fairly similar. What OS X needs is a good C++ oriented API. It doesn't have to be based on Cocoa directly, because some of the concepts don't work in both places, and I don't think that it would be bad if a C++ API set was designed with slightly different goals in mind.

 

[Sander]

I gave up on the throught of "pure" C++ Cocoa programming, and am knee-deep in Objective-C at the moment. After finishing Hillegass's book, I will investigate Objective-C++ to see whether I can get a "best of both worlds" situation. If I can only get the RAII idiom to work (Resource Allocation Is Initialization - a weird name since the most important aspect is actually "Object Leaving Scope Is Resource Deallocation"), I will be happy. Whenever I read another reminder of retain/release pitfalls, I cringe and wish I could use C++.

I got peace of mind however by replacing "C++ is not dynamic enough to be useful for Cocoa" by "Cocoa is not static enough to be suited for C++" in my mental picture. It's the same thing, but it sounds less condescending to C++ and hence makes me feel better.

 

[laprej]

I gave up on the throught of "pure" C++ Cocoa programming, and am knee-deep in Objective-C at the moment. After finishing Hillegass's book, I will investigate Objective-C++ to see whether I can get a "best of both worlds" situation. If I can only get the RAII idiom to work (Resource Allocation Is Initialization - a weird name since the most important aspect is actually "Object Leaving Scope Is Resource Deallocation"), I will be happy. Whenever I read another reminder of retain/release pitfalls, I cringe and wish I could use C++.

I got peace of mind however by replacing "C++ is not dynamic enough to be useful for Cocoa" by "Cocoa is not static enough to be suited for C++" in my mental picture. It's the same thing, but it sounds less condescending to C++ and hence makes me feel better.

I guess I just don't get the mindset at work here. C++ is better than Objective-C? Ultimately both languages are hacks plain and simple. C++ started out as C with classes and really looked nothing like modern C++. Similarly Objective-C was C with some non-overlapping syntax thrown in to support objects. One isn't better than the other, though you could argue that one is more suited to a specific task.

 

[Soulstorm]

Objective C and C++ were created with different goals in mind. C++ forces utilizing more low-level mechanics than ObjC, but it often requires more effort to to a simple thing. On the other hand, ObjC provides classes and functions that solve many problems that most programmers encounter during development.

With C++, you mostly think how you are going to make something. With ObjC, you mostly think what are you going to make.

That said, as I have mentioned in another post, the main difference between C++ and ObjC is this: Suppose you want to make a car. You will use C++ to make the engine compartment, and ObjC to make interior of the car, the seats, and generally everything that contributes to the look-feel and the behavior of the car.

I think that C++ and ObjC can be used together in a program to achieve great results. A proficient C++ programmer should have no problem using C++ with Cocoa.

However, I really wish Apple would release a pure C++ oriented API. Cocoa seems to rely on ObjC too much. I think that a pure C++ API (with simple support for ObjC, as it is now with Cocoa and C++) will make happy those unsatisfied with Cocoa,it will draw even more developers to OS X, and finally it will cover some needs that cannot be fulfilled with Cocoa and ObjC.

 

[robbieduncan]

However, I really wish Apple would release a pure C++ oriented API. Cocoa seems to rely on ObjC too much. I think that a pure C++ API (with simple support for ObjC, as it is now with Cocoa and C++) will make happy those unsatisfied with Cocoa,it will draw even more developers to OS X, and finally it will cover some needs that cannot be fulfilled with Cocoa and ObjC.

I personally can't see why Apple should spend millions of dollars developing a C++ API that might end up being as good as what they have now. There are millions of lines of code already written by Apple and third-party developers for their applications in Obj-C/Cocoa. These developers would be very unhappy with a re-written API where Obj-C was only just about supported.

Basically C++ is not the chosen route for OSX or iPhone development. Get over it.

 

[Littleodie914]

With C++, you mostly think how you are going to make something. With ObjC, you mostly think what are you going to make.

Exactly.

 

[lee1210]

Language flame wars are useless. If you love a particular language so much that you can't consider the use of another, you have not learned to program you have learned a single model through a single language. There are languages that are terribly suited for particular problems, but it doesn't make that language terrible in all cases. You might not want to write a GUI in Fortran, but you probably don't want to write numerical analysis routines in VB.net.

If you think Objective-C is terrible, and there are certainly avenues by which to attack it, you are absolutely free not to use it. Making that choice will limit the platforms you can target, due to technical decisions made by those who are most likely more experienced with platform design than yourself. Carbon is on its way out, so C++ isn't really an option there. However, there are now bridges for Ruby and Python, so you don't have to use Objective-C to use Cocoa. If the remaining argument is "Well, I can't use C++ as a 'first-class' language with Cocoa, those other options are no better than Objective-C" then you're simply saying "I don't want to ever program in anything but C++". I believe the saying goes "When the only tool you have is a hammer, everything looks like a nail". It turns out that Cocoa isn't much of a nail after all, so you might need a new tool.

In reality, you should have the layers of your application separated to the point that all of the logic and data access code is separate from the GUI anyway. You should have no problem writing your logic and data access code in C++, then hooking up the GUI in Objective-C as lightweight hooks to your C++ logic layer. This would require a very minimal amount of Objective-C and your application would essentially be C++.

I didn't really mean to rant, but I have a deep-rooted disdain for language favoritism. Every day I read and write code in C, Fortran 95, Java and less often Perl and shell. In my free time I'm researching Objective-C and writing a little here and there, mostly to assist on these forums. When I feel like I have a strong handle on that I'll probably move to Ruby or another "newer" language to see what's on offer from a more recently designed language. I love to program, and enjoy learning new things. If you have to program and don't love it, and don't get excited about new things I would understand the resistance to learning a new language, but otherwise I'd say you should never miss an opportunity to broaden your horizons.

-Lee

 

[Eraserhead]

^^ +1. You've got the nail on the head.

The only real issue with Obj-C is that you have to put a [ at teh beginning, but its hardly a fatal issue.

 

[CPlusPlusMan]

I've yet to hear a single flame... maybe RobbieDuncan's final line "Get over it" could be maybe considered somewhat harsh, no one's flaming... I'm just being honest.. I don't like Obj-C...

Secondly: I like C (but I want to do OO), I like shell scripting (I don't know what I'd do without it), I like Python (favorite scripting language), I've seen perl code and I have a deep appriciation for it (but I don't know it very well, nor python). there's only two languages that I actually hate (I don't care much for assembly but that's because it's way too low level for my practicality, it is a very interesting and intriguing language). The first is Java. if you don't understand why I hate it ask yourself why printline() requires you to write it's library name and class name when a much better global paradigm would have been more accessable (like "println();"). No language should force OO especially since OO is not appropriate for every problem and solution. The second is Objective C... and I've already told you why I so strongly dislike it. Admittedly it has a better runtime but that's not the language's advantage nor it's fault... that's the implementer's doing. C++ as a language is lacking a well written runtime. MS just care's about the runtime being MS specific to the point of locking in your code. Apple completely ignore's it. GNU just want's it to work and doesn't care if it works elegantly. These are implementation problems, not language design issues. I can also see that I'm not the only one who prefers C++ to Obj-C for application development. why is apple ignoring potential new Developers who wish to write for their platform.... do they really think they can spit in our faces like that and get away with it? I think not!

 

[lee1210]

I didn't mean to be harsh saying it's a flame war... is holy war better? I guess I just meant nit-picking and language favoritism. I'm clearly not going to try to convince someone with the moniker CPlusPlusMan that Objective-C isn't so bad . I don't think Objective-C (and by extension Objective-C++) is spitting in the face of developers that are familiar with C++.

The NeXTStep engineers and later Apple engineers felt that Objective-C was the best for the respective platforms, and for better or worse that is what we have. Yes, this may deter some developers but you can't please everybody all the time.

On linux for system level things you have to use C, which is easily done directly from C++, via JNI for Java, and I'm sure through a number of other mechanisms for other languages. Does this make some things more difficult in higher level languages? Sure, but that's what Linus and co. decided was best for the platform. Microsoft has thought a lot of things are best, and VC++ was the top of the heap until .NET came along.

In all of these cases, some developers who have a favorite language are left out in the cold if they don't want to deal with the specifics of the system. Sometimes if you want to play in someone else's sandbox you can only play with the toys they chose. I'm sure some very talented developers would prefer to write all of their apps in Common Lisp, but no popular platform that I know of has APIs available to Lisp. That's the breaks sometimes.

For cross platform development your GUI code will have to be different no matter what (er, I guess maybe not with Swing or AWT or GTK or wxWindows...). As long as you have good delineation between the layers of your application, tying any GUI into your actual application code for all but the most trivial of projects should be the least of your worries. Actually having a functional logic layer and data access layer is likely to be much more difficult.

Hopefully that was more civil, but probably doesn't soothe anyone's feelings on the matter.

-Lee

 

[laprej]

This has to be the most passive (non) flame war I've ever witnessed...

 

[therevolution]

CPlusPlusMan,

Here's what I get from your posts:

• You don't like Objective-C because it looks ugly and not C++-like.
• You don't like Java because 'System.out.println()' is so much worse than 'println()'.

Languages are not religions, they are not fan clubs, they are not sports teams. Languages are tools designed to solve problems. They often take different approaches and are designed with particular paradigms or philosophies in mind. They are made by people who have different histories and different ideas than you.

What your arguments say to me is that you don't have a good understanding of Objective-C (or Java for that matter) and the paradigms they embrace. They say that you prefer to reject the unfamiliar rather than attempt to understand it. That's your choice to make, but I think most of us realize that it's unproductive to think that way. In the end, you are just limiting yourself as a developer.

And to suggest that Apple is "spitting in your face" for having not adopted your favorite language? Yeeeeah... okay.

 

[robbieduncan]

I've yet to hear a single flame... maybe RobbieDuncan's final line "Get over it" could be maybe considered somewhat harsh, no one's flaming...

Lol, I did think long and hard about putting that in there. I think my post comes from the exact opposite side of the argument to you: I really dislike C++. It's just not well designed at all. Give me Java or Obj-C+Cocoa (need the class libraries) any day.

 

[Krevnik]

Lol, I did think long and hard about putting that in there. I think my post comes from the exact opposite side of the argument to you: I really dislike C++. It's just not well designed at all. Give me Java or Obj-C+Cocoa (need the class libraries) any day.

I personally don't dislike C++ all that much, but I don't think a language is done justice if the class libraries for it don't play to its strengths. (For example, a really good STL implementation is better for C++ than CoreFoundation, IMO)

Cocoa does not play to C++'s strengths, and I think to assume that Cocoa should really be C++-compatible, and that Apple is evil for not doing so doesn't make a whole lot of sense to me.

Cocoa is very much playing to a lot of Objective-C's strengths. And does things I would not expect to be feasible in C++ without a big perf hit of some kind (KVC for bindings, as an example).

Cocoa is really just an expanded/updated version of the NeXTStep API from over a decade ago. It doesn't surprise me that Apple used it to save time, and that they don't see the point in doing the heavy work required to make it C++ and Objective-C friendly. Not when new features like CoreData require a dynamically typed environment to be so dead simple.

 

[yeroen]

It's been said already, but a C++ interface to Cocoa (what would that mean, exactly?) wouldn't make C++ better, it'd just make Cocoa worse. The object models, run-time environment, and language implementations of OO features are just too different. Just look at Objective C++ as an example of how the respective language features are kept safely walled off from one another. This is no slight against C++ as a language, in which I've coded professionally for the past decade. It's just an acknowledgement that some 'orthogonal' things should stay orthogonal.

If the OP is looking for Cocoa-like functionality in C++, then I recommend Qt as an excellent cross-platform framework (yes, it does native look and feel Aqua GUIs).

 

[Krevnik]

I think I have to second the Qt remark. I have been pretty impressed with the general level of polish Qt-based apps have on the Mac. It isn't perfect, certainly, but dev builds of Stellarium using Qt are pretty slick in full-screen mode.

 

[lazydog]

Whenever I read another reminder of retain/release pitfalls, I cringe and wish I could use C++.

Totally agree with this. RAII along with smart pointers makes for a nice memory management in C++. Most of the work of a garbage collector is already done by RAII.

b e n