macOS C++ interface to Cocoa?

[kainjow]

I was glancing around Apple's developer website and came across some tutorials for using Cocoa classes in Carbon (see here).

I'm assuming that from this knowledge, one could write a C++ frontend/api/whatever for accessing Cocoa classes, correct?

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).

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... )

 

[bousozoku]

C++ isn't the right kind of language (it's Object-oriented, but just) to talk to Cocoa directly but you could create an application framework that would allow you to access Cocoa indirectly from C++.

 

[Soulstorm]

C++ isn't the right kind of language (it's Object-oriented, but just) to talk to Cocoa directly but you could create an application framework that would allow you to access Cocoa indirectly from C++.

Indeed. But the problems you will encounter are not because of Cocoa, but because of the language used to access the API.

The biggest problem you have to deal with is the way you are going to treat the collections and sets og objects, like NSArray for example. The only formal equivalent I know of in C++ is the vector of the STL. But still, it is a teplate and it requires to deaclare from the start what objects this vector will hold. The same thing happens with every aspect of C++. Objective C's collections and sets allow objects of dirrerent classes to be stored in the same array, something that could not happen with C++.

You have to deal with these problems first, and I just can't think of any way around it, and frankly, if you eventually manage to create such a framework I think that the functionality that would offer would be too limited considering the amount spent to build it. Especially since C++ faithfull devs have Objective C++ at their disposal.

 

[kainjow]

C++ isn't the right kind of language (it's Object-oriented, but just) to talk to Cocoa directly but you could create an application framework that would allow you to access Cocoa indirectly from C++.

I realize that, but it seems possible to write a complete C/C++ wrapper for Cocoa classes.

Concerning arrays, you would probably use CFArray which I believe can hold any object (NSArray uses CFArray).

 

[Catfish_Man]

Certain parts of Cocoa would be exceptionally difficult to do in C++. Distributed Objects, for example... I guess you'd have to do something like store a hash table of name->function pointer for each member function, which is basically what objc is doing anyway.

 

[bousozoku]

I realize that, but it seems possible to write a complete C/C++ wrapper for Cocoa classes.

Concerning arrays, you would probably use CFArray which I believe can hold any object (NSArray uses CFArray).

You'd be better off creating a great C++ application framework over Carbon that would add some Cocoa-like behaviours. It's much easier for a language like Objective-C to handle statically-typed code than it is for C++ to handle dynamically-typed code. Java was well-suited to Cocoa and so is Smalltalk. I've seen one Smalltalk-like framework done in C++ but it was rather bulky to emulate all the good stuff.

 

[Catfish_Man]

You'd be better off creating a great C++ application framework over Carbon that would add some Cocoa-like behaviours. It's much easier for a language like Objective-C to handle statically-typed code than it is for C++ to handle dynamically-typed code. Java was well-suited to Cocoa and so is Smalltalk. I've seen one Smalltalk-like framework done in C++ but it was rather bulky to emulate all the good stuff.

Even Java was rather poorly suited, and it shows in the clunkiness of parts of the Java-Cocoa API.

 

[bousozoku]

Even Java was rather poorly suited, and it shows in the clunkiness of parts of the Java-Cocoa API.

I suppose I should have said better-suited than C++. It wasn't so bad, though.

 

[findhornriver]

http://www.refnum.com/products/nano/index.html

Not an interface to Cocoa, but rather a very nice C++ library for Carbon apps. It's released under the Open Source BSD licence ("This licence allows usage in both Open Source and commercial software, and does not require any reciprocal licencing or release of source code when incorporated into commercial software.") I include a reference to Nano in the About dialog and a copy of the copyright notice - which is all the Nano creator asks.

I've used it to make a couple of quick apps for work and it's rather well implemented. The header files document the class usage so they need to be read. Using Nano I write complete C++ apps for Tiger (haven't tried earlier versions) and have had no problems with it at all.

Apparently it is Leopard ready.

It's a free download so have a look.

 

[kainjow]

findhornriver, that's essentially how every other C++ cross platform app is made, is with Carbon because it's already C based. I'm interested in Cocoa because Carbon apps tend to be ugly and not OSX-ish... But Nano does seem to be more well implemented than other frameworks.

 

[findhornriver]

As mentioned by previous posters you will have to learn Obj-C to use Cocoa.. sorry.

 

[kainjow]

As mentioned by previous posters you will have to learn Obj-C to use Cocoa.. sorry.

Arg, I realize that! But according to the articles above, you can write functions to wrap around Cocoa calls, so it could be possible to write an ugly C++ classes around those functions... I'm not saying I'd ever want to do this, I'm just thinking about what's possible

 

[GeeYouEye]

I tried it. It's insanely difficult. Possibly impossible. C++ is not dynamic enough. And you'd still have to write your controller class declarations in Objective-C, though not necessarily the implementations (you have to use Obj-C for the prototypes and each method declaration, but once inside the {} you could use C++).

For example, how the heck do you get anything in C++ to work with the poseAsClass: family?

I think one of my comments in the wrapper code for NSInvocation (not at my Mac at the moment) was something along the lines of. "They say C lets you shoot yourself in the foot. They say C++ makes it harder but when you do you blow the whole foot off. Here, I'm giving you a gun firing depleted uranium shells pointed right at your kneecaps. Don't misuse this." I realized then that if I had to place such constraints here, it was only going to get worse later.

There's the problem of whether or not to follow the class hierarchy and use use virtual functions. It sounds like a great idea to do it that way, except it exaserbates the controller problem, because you can't have any C++ classes with virtual functions as members of an Objective-C class.

And there's size: Every increase in depth of the class hierarchy introduces a new ivar. So classes grow O(n)+O(1) with depth, rather than O(1), the number of additional ivars; the NSObject in SYNSObject, the NSObject and NSData in SYNSData. The NSObject, NSData and NSMutableData in SYNSMutableData.

There's a way to get around it; declare id _myPrivateInternalObject; in SYNSObject and SYNSProxy (and I don't even care to think about what Distributed Objects, or worse, Portable Distributed Objects, would take to get working). But that introduces a whole host of problems.

I'm not, necessarily, saying that it's completely impossible. I am saying it's not worth it, especially because the controller langauage problem is insurmountable.

 

[GeeYouEye]

http://www.refnum.com/products/nano/index.html

Not an interface to Cocoa, but rather a very nice C++ library for Carbon apps. It's released under the Open Source BSD licence ("This licence allows usage in both Open Source and commercial software, and does not require any reciprocal licencing or release of source code when incorporated into commercial software.") I include a reference to Nano in the About dialog and a copy of the copyright notice - which is all the Nano creator asks.

I've used it to make a couple of quick apps for work and it's rather well implemented. The header files document the class usage so they need to be read. Using Nano I write complete C++ apps for Tiger (haven't tried earlier versions) and have had no problems with it at all.

Apparently it is Leopard ready.

It's a free download so have a look.

Very interesting. Looks like a great addition to Carbon. Could even encourage new adoption of it. which is not necessarily a bad thing. Very interesting that it links against QuickTime and Accelerate

 

[GeeYouEye]

Thinking a bit more on it, I've almost been inspired to break out the old code and see if I can get a bit more of it working. BUT 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.?

 

[kainjow]

A small sample

Well I've been procrastinating all day (stupid physics test) and decided to try out my ideas on this whole C++ wrapper thingy.

I have a working example with 3 simple objects: CCObject, CCString, and CCAutoreleasePool.

You can grab the code here: http://kainjow.com/code/CPPCocoa.zip

Here's a shortened version of my main():

int main(int argc, char *argv[])
{
	CCAutoreleasePool *pool = new CCAutoreleasePool();
	
	CCString str1("hello");
	const char *cstr1 = str1.UTF8String();
	printf("str1: %s (%d)\n", cstr1, strlen(cstr1));

	pool->Release();
	
	return 0;
}

It uses GeeYouEye's idea of having a private variable in each class that represents the Objective-C object, although I only noticed he posted about that after I already designed the classes.

I'd love to see what you guys think I don't plan on taking this much farther, it's mostly just an experiment.

Edit: it's freaky to realize I posted this thread almost a year ago. Seems like yesterday!

 

[Catfish_Man]

You guys might find this interesting: http://michelf.com/weblog/2007/d-objc-bridge/

 

[GeeYouEye]

Well I've been procrastinating all day (stupid physics test) and decided to try out my ideas on this whole C++ wrapper thingy.

I have a working example with 3 simple objects: CCObject, CCString, and CCAutoreleasePool.

You can grab the code here: http://kainjow.com/code/CPPCocoa.zip

Here's a shortened version of my main():

int main(int argc, char *argv[])
{
	CCAutoreleasePool *pool = new CCAutoreleasePool();
	
	CCString str1("hello");
	const char *cstr1 = str1.UTF8String();
	printf("str1: %s (%d)\n", cstr1, strlen(cstr1));

	pool->Release();
	
	return 0;
}

It uses GeeYouEye's idea of having a private variable in each class that represents the Objective-C object, although I only noticed he posted about that after I already designed the classes.

I'd love to see what you guys think I don't plan on taking this much farther, it's mostly just an experiment.

Edit: it's freaky to realize I posted this thread almost a year ago. Seems like yesterday!

I don't have time to go through the code sample right now, but I'm very curious: where are you keeping the CCString's id (or NSString *) ivar, and how are you dealing with memory management? And if you've managed to figure that out, why is pool a pointer?

 

[kainjow]

I don't have time to go through the code sample right now, but I'm very curious: where are you keeping the CCString's id (or NSString *) ivar, and how are you dealing with memory management? And if you've managed to figure that out, why is pool a pointer?

CCObject has a private _baseObj ivar that is the base Objective-C object for the class, and each subclass sets this variable. Here's how CCString does it:

CCString::CCString(const char *string)
{
	id obj = [[NSString alloc] initWithUTF8String:string];
	this->SetObjCObject(obj);
}

pool is a pointer just so it is consistent with the convention of how NSAutoreleasePool is used. You could also create it like this:

CCAutoreleasePool pool;

and it would work just fine.

 

[Bobbyski]

Nothing is impossible

I would like to know if you are continuing to pursue this concept? I believe that that this is a worthwhile project. I love Cocoa but hate objective-C, I would gladly pay for C++ wrappers for Cocoa. C++ is still the most popular programming language. I am and always will be a C++ programmer, though I find myself using objective-C more and more.

I have told people that wanted me to write stuff for them, nothing is impossible - just impractical and too expensive. This is a hard project, but I think it is one that could pay off in a big way.

I want to say, please continue to pursue this, and if you choose to create an open source project, I will be glad to contribute as time permits (As long as it's not GPL).

 

[kainjow]

I won't be contributing anymore to this. If you want you can continue it, post it on Google Code or whatnot. Just give me the original credit and put it under BSD license (which it already is, see the license.txt that is in the zip above).

To use a custom class you'd still have to write the custom Objective-C class, then write the corresponding C++ class to wrap that Obj-C class.

You're better of just learning Objective-C, which isn't hard at all if you know C++ and OOP. I just did this one day as an experiment.

Good luck.

 

[GeeYouEye]

I would like to know if you are continuing to pursue this concept? I believe that that this is a worthwhile project. I love Cocoa but hate objective-C, I would gladly pay for C++ wrappers for Cocoa. C++ is still the most popular programming language. I am and always will be a C++ programmer, though I find myself using objective-C more and more.

I have told people that wanted me to write stuff for them, nothing is impossible - just impractical and too expensive. This is a hard project, but I think it is one that could pay off in a big way.

I want to say, please continue to pursue this, and if you choose to create an open source project, I will be glad to contribute as time permits (As long as it's not GPL).

I'll look at it again. But the controller problem is still insurmountable without rewriting Interface Builder using the C++ wrapper.

EDIT: What is it about Cocoa that you want? If it's just the class library, that can be done relatively easily, although you'll be coding with Objective-C idioms most likely. But there's a lot of Cocoa that's tied into Objective-C because of its dynamic abilities (and thus why there's RubyCocoa and PyObjC thriving while Cocoa Java is dead and C++Cocoa doesn't exist at all.)

 

[Bobbyski]

Obstacles

I'll look at it again. But the controller problem is still insurmountable without rewriting Interface Builder using the C++ wrapper.

EDIT: What is it about Cocoa that you want? If it's just the class library, that can be done relatively easily, although you'll be coding with Objective-C idioms most likely. But there's a lot of Cocoa that's tied into Objective-C because of its dynamic abilities (and thus why there's RubyCocoa and PyObjC thriving while Cocoa Java is dead and C++Cocoa doesn't exist at all.)

There is a great deal about Cocoa to love. The GUI controls are the most desired aspects, so that I can write C++ applications that look and feel like full Cocoa applications. But the underlying Cocoa libraries are all great too. Apple (or shall I say NeXT) seemed to put a lot of thought into proper Object Oriented design (though they rely more on "helper" classes than inheritance). Finally, I am always impressed by how little code I have to write to do anything.

I see the issues with the model view controller nature being a big stumbling block, as that is what has prevented me from pursing using C++ from the beginning.

I kept telling myself that I needed to learn Carbon as Apple brought it closer to Cocoa, but now that seems like a dead end path as it will no longer grow closer but settle further behind.

Though I love the Interface builder, that is the component that is easiest to give up as I am perfectly capable of writing a GUI design tool for a good C++ library.

For me the largest obstacle is that I do not know how tow write a Cocoa GUI program with out using a NIB. If someone has an example of how to do this, then I would have a point of reference, but I don't have this so there is a lot that I don't know that needs to be discovered.

Right now I tend to design GUI's with IB and then call C++ classes to do the work and my biggest problem is that this process is that I have failed to become an obj-C expert so when I have errors in this portion they are a royal pain ... obj-C tends to be much more difficult to debug as the Dynamic nature of it lends itself to unexplained runtime errors generated by simple typing errors.

I would like to see if anyone has any sample of NIBless cocoa GUI apps that I could see, then I would start the project myself. First as a class library then later adding the GUI tool.

 

[lazydog]

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

b e n

 

[lazydog]

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

b e n

Sorry, please totally ignore my post… it's completely irrelevant! I remember seeing an attempt at wrapping Cocoa in C++ but that wasn't the link.

b e n