[smileyq]

I'm learning C++ finally and want to know how I would go about building an interface for a C++ program with Interface Builder. I've read that you can't use C++ and Cocoa but you can use it with Carbon. Anybody know of any good sites to guide me in the right direction? Thanks

[kamprath]

Originally posted by smileyq:
<STRONG>I'm learning C++ finally and want to know how I would go about building an interface for a C++ program with Interface Builder. I've read that you can't use C++ and Cocoa but you can use it with Carbon. Anybody know of any good sites to guide me in the right direction? Thanks</STRONG>

There is no "public" C++ application framework that integrates with IB that I know of. I personally wrote my own - it wasn't that hard since Carbon Events are very OO-ish in the first place. The basica idea to writing your own would create a basic class that wraps around a Carbon Event handler, then most everthing will inherit off of that (Windows, menus, command handlers, etc). The beatuty of writing your own is that your framework will be very light and not incur the overhead of fully matured frameworks. The draw back is, of course, you have to write your own Someday I ight make my C++ carbon event framework public, but it's still very specific to my own needs right now.

You could try MacZoop (www.maczoop.com), but AFAIK, it doesn't integrate with IB yet, and is still geared towards resource based applicaitons. Also, MacApp has a C++ Carbon framework in it. I am not familiar, though, with its level of itegrations with IB.


Michael Kamprath

[Rickster]

Thanks to Objective-C++, you can do this kind of thing pretty easily with Cocoa. You can't have the interface objects talk directly to your C++ code, but you can have an ObjC++ controller object that acts as a go-between, calling C++ functions from within ObjC methods. You cen even still use IB's "Create Files" feature to automatically build skeleton source code files -- just rename the implementation file to .mm instead of .m, and it'll go through the ObjC++ compiler allowing you to use C++ features within the ObjC methods.

[Jeff Binder]

If you're interested in Obj-C++, read this oft-linked-to page: http://developer.apple.com/techpubs/...ctive-C++.html
It explains what Obj-C++ can and can't do.

[kamprath]

Originally posted by Rickster:
<STRONG>Thanks to Objective-C++, you can do this kind of thing pretty easily with Cocoa. You can't have the interface objects talk directly to your C++ code, but you can have an ObjC++ controller object that acts as a go-between, calling C++ functions from within ObjC methods. You cen even still use IB's "Create Files" feature to automatically build skeleton source code files -- just rename the implementation file to .mm instead of .m, and it'll go through the ObjC++ compiler allowing you to use C++ features within the ObjC methods.</STRONG>

However, you can not use C++ to sub-class Objective C objects, which leaves with you with three choices:

1. Program Cocoa procedurally with the C'ish aspects of C++ - ICK! Why use an OO language then? You might as well program Carbon procedurally.

2. Write a C++ wrapper class for each Cocoa object so that you can use OO-programming in C++ - Double ICK! The amount of work that is needed to fully encapsulate all objects being used is about the same amount of work to learn Objective C, or the amount of work to write a light weight framework for Carbon in C++. If you want to use Cocoa, learn objective C. Objective C++ is intended only to bridge legacy code with the Cocoa application framework.

3. Program in Carbon - Ahhhh . . . (see my comments above).

Think of things this way. There are two API's to make GUI on MacOS X, one an OO framework, the other a procedural API with an OO-ish structure. To leverage the power of the OO framework (Cocoa), you need to be able to do OO things with it's interface (sub classing, etc). Unfortunately, Cocoa is written in Objective C, whose object structure is NOT compatible with C++'s object structure - Objective C++ just makes C++ and objective C link compatible with some syntaxt for the direct interfacing in the code. If you don't understand the significance of that (no, it's not to program Cocoa in C++), then you haven't been around the science & engineer community to long. Here's clue: Apple would have an absolute coup on their hands if they came up with "Objective FORTRAN" so engineers can put Cocoa front ends on their FORTRAN code. Heck, I think most engineers would be giddy about FORTRAN & C++ compilers that were not only link compatible, but syntax existed so you could call FORTRAN directly from C++.

Rather than going through heroic efforts to program Cocoa in C++, either learn Objective C (really, it's not that hard), or program Carbon in C++.

Michael

[ 04-15-2002: Message edited by: kamprath ]

[Rickster]

However, you can not use C++ to sub-class Objective C objects, which leaves with you with three choices:
...
Rather than going through heroic efforts to program Cocoa in C++, either learn Objective C (really, it's not that hard), or program Carbon in C++.

It doesn't have to be that terrible. Depending on how your program is organized, you might be able to have C++ and ObjC objects coexisting. If you already have a body of "backend" code (also commonly referred to as the "model" or "business logic") that's in C++, and you'd like to create an Aqua interface for it, the easiest way is probably ObjC++.

In a proper object-oriented program in any language, you'd want to follow the Model-View-Controller architecture: the user interface code is kept completely separate from the model objects, and one or more controller objects coordinate the interaction between view and model. So, you can have an ObjC controller objec that instantiates and manipulates C++ model objects and controls ObjC view objects. It works quite nicely... I'm using this approach for a personal project right now (giving a real Cocoa UI to a C++ GLUT app, and ending up with much simpler UI code).

Of course, if you're programming something new from scratch, you're generally better off either going all-ObjC with Cocoa or all-C++ using one of the various Carbon application frameworks like PowerPlant.