A lot of questions!

R

RomanticWarrior

Registered
Hi,
I'm a fairly new programmer who have been coding some simple MacOS 9 PPC apps with CodeWarrior Pro 4. Now that OS X's release is coming close, I want to get ready to program Carbon/Cocoa apps. But, I am totally confused.
I use CWPro4, and I felt the need to upgrade to 6. Does anyone know if the current verison of CodeWarrior Pro 6 or Apple's Project Builder supports development of Carbon apps on OS9.1? I emailed Metrowerks and they said since I use CWPro4 they can't support me. Didn't make any sense.
Any guess as to when Metrowerks will release a OSX native version of CodeWarrior? What are the benefits of Cocoa over Carbon? I am eager to code my own little game using Carbon or Cocoa API, but I am confused and frustrated with all the things (Carbon SDK Carbon Lib Project Builder Universal Headers etc) that seems to be what I need to get started with Carbon/Cocoa development. Are there any good documentation out there that explains Carbon/Cocoa in a programming-level? I am waiting for MacTech to release the OS X version of their programming guide, but seems like it will take a long time.

Thanks,

RW
 
Hello,
It appears I get first crack at answering your questions :->

...supports development of Carbon apps...
Codewarrior 6 can create X/9.n carbon apps. InterfaceBuilder, although free, pales in comparison.

...Didn't make any sense...
I agree. They obviously do not know how to sell an upgrade. hmmmm.

...Metrowerks will release a OSX native version...
Already done in 6. Its not perfect but neither is carbon.

...benefits of Cocoa over Carbon...
Do you want to start a religuos war here :-> Carbon is C++, Cocoa is Objective-C. Carbon lets a developer leverage existing knowledge and the syntaxual benifits of C++. Cocoa lets the developer interface with services not readily available with C++ and run in a more native environment.

The primary functional difference is how the run-times handle virtual methods. C++ links functions at compile-time. It is fast, type safe, but not very dynamic. Obj-C treats function calls like messages. You can call a "function" in an object that does not exist. You gain run-time dynamics at the cost of speed with Obj-C.

...good documentation...
Some great documentation comes with the free developer tool kit from Apple. They are basically the new "Inside Macintosh" books. I cannot remember where I got it but for Cocoa apps try "The Vermont Recipes."

Hope this helps

Jove

 
Thanks for your quick response.

One thing you said that surprised me is "Objective-C".
I thought it was a synonym for "C++"!
So I guess there's a new version of C++ out there.
I'm just done studying C right now. Gotta catch up!

I'll look into Apple's developer web site. I was hoping for some 3rd party documentation that eases the learning (Apple's Macintosh Toolbox is a bit too difficult for me to understand). I guess there are no shortcuts for now ;)

Oh, one more question.
Do Macintosh programmers still have to be concerned with the Pascal code of the Toolbox? Are they optimized for C/C++ in OS X?

Thanks in advance,

RW
 
Obj-C vs. C++ (my take):

Objective C is an object oriented language, whereas C++ is a procedural language in which it is possible, if you really want to try, to write O-O programs.

With Cocoa, the toolbox is a thing of the past. From my understanding, Carbon is essentially there as a toolbox emulation environment. It allows developers who know the toolbox from earlier experience to continue to code without too much new learning. Cocoa is by all accounts a good bit easier to write programs for, if you are going to be learning either one from scratch anyway.

jove gave you a good tip with the Vermont Recipes - that is some really well and concisely explained stuff, with pointers to the full documentation.
 
Hello,

Both C++ and Obj-C are based on the procedural flat language "C". You can compile basic C code in either environment.

That is where the similarities end. Scruffy was correct except I wouldn't downplay C++ too much. Apple is the only computer I know of with an Obj-C compiler. Learn C++ and you'll be more marketable.

Many developers prefer C++ because a) its what they know, b) it produces faster executable code, c) it is stricter, therefore more structured with types and functions d) The language syntax is very versatile.

I have discovered Obj-C's laxness makes up for C++'s versatility. In other words C++ has become very complex to achieve the dynamics inherent in Obj-C.

Carbon is not just a toolbox emulation. Apple is using Carbon to bridge managers and functionality between legacy MacOS9 and X. QuickTime in X uses Carbon. The MacOSX XML engine ported to 9 uses carbon. I believe we will see many Xisms in 9.5 via the CarbonLib.

As far as documentation - please get Apple's developer docs. There are well written and cover everything between system architecture and the individual API's. In fact everything we have discussed here is documented in those PDF files.

I have ranted on long enough...
Jove
 
CarbonLib isn't C++, it's pascal. Well it's written in C but the interfaces are extern pascal.

Objective-C is really easy to learn if you know C. Takes less than a day. For this reason I don't consider it prudent to avoid ObjC because C++ is more 'marketable'. C++ may take months to master, but ObjC doesn't. There is virtually no cost in learning the language (the Cocoa API on the other hand is a different matter).

Apple's tools can build Carbon and Cocoa applications. Interface Builder supports both as well.

Carbon is not emulation.

Carbon doesn't have anything to do with Classic. Services shared by Carbon, Classic, and Cocoa (and Swing too I presume) aren't tied to any specific library/virtual machine. For example for Classic to get text copied from a Cocoa application does not involve Carbon, it only involves pbx.
 
Hello,

There are three primary aspects to a language package - synatx, built in libraries, and methodology. The syntax is easy. The methodoly isn't difficult but very different. And the libraries, which makes the language useful, have a cost associated with learning. Learn C++. I do not care about learning curves. Any job that wants Java, C++, or even Visual Basic programmers is not going to care about Obj-C.

Apple's tools do not have equal functionality between carbon and cocoa. I do not believe the "Services" architecture is even available in carbon. If you are ONLY interested in programming on X - then learn Obj-C.

Carbon is not emulated? As far as wrapping some of MaxOSX APIs in flat C/C++ API - Yes it is. CarbonLib includes new functionality, stubs to interface with MacOS 9, and stubs to interface MacOSX. Unfortuanately it is a moving target. CarbonLib for X is not satisfactorily equivelant to CarbonLib on MacOS 9.

Jove
 
Originally posted by jove

Carbon is not emulated? As far as wrapping some of MaxOSX APIs in flat C/C++ API - Yes it is. CarbonLib includes new functionality, stubs to interface with MacOS 9, and stubs to interface MacOSX. Unfortuanately it is a moving target. CarbonLib for X is not satisfactorily equivelant to CarbonLib on MacOS 9.

Jove
Click to expand...

You have a weird definition of emulation. Actually not so much weird as totally wrong.

And Carbon is not C/C++, how many times do I have to say this?

MacOS X services can be accessed by the Cocoa or Carbon API. Carbon is not a wrapper for Cocoa. Carbon is not emulated. There is nothing emulated about Carbon. It's like saying Cocoa is emulating OpenStep, pure rubbish.
 
Strobe,

We can argue until we are blue in the face about semantics. Emulation is a wrapper. It does not matter if the wrapping occurs at the processor level or at the API level.

I never said carbonlib IS C/C++. The original motivation behind creating CarbonLib was to provide a C/C++ API and run-time environment to access the OpenStep/Cocoa libraries. That is a wrapper. With an admittedly broad definition it IS emulation.

Not all MacOSX services can be accessed from C/C++. I have yet to see a MacOSX C/C++ app with a services menu item. Will it be possible? Sure. It is analogous to porting the PPC native Code Fragment Manager to 68K. Over time Apple was able to emulate, yes emulate, that advanced architecture under 68K.

Jove

PS.
Another poster has pointed out that you are getting, well, snippy. The arrogant tone you take, especially when you are either wrong or confused, is just totally wrong and pure rubbish :->
 
bzzt, WRONG!

Like I told you before, Carbon is NOT A WRAPPER!

Gee, I wonder how shocked you would be to find out NSMenu is a wrapper for menu drawing code which is basically Carbon. Oops, I guess that makes Cocoa emulated.

In fact Cocoa apps link to CarbonLib, yet Carbon apps do not link to AppKit. Oops there goes your wrapper supposition.

OPENSTEP 'Services' are obviously not to what I was referring. Services is a more general term like pasteboard, CoreGraphics, and 9 out of 10 libraries in OS X which are **NOT** "OpenStep/Cocoa Libraries"

In fact most of them were borrowed from MacOS, only a few from OPENSTEP.

I guess I better say it again, Carbon is NOT A WRAPPER. That makes it at least three times, I hope you get it now.
 
Hello,

Yes I am making assumptions. I assumed that Apple did not rewrite most OpenStep services just to throw a C/C++ API on top of them. Are you saying that Apple did not wrap any OpenStep functions/objects services in Carbon? That is a serious question - not rhetorical.

I understand that Apple has ported from Classic and created many new libraries for X. But comparing the system documentation with old Rhapsody documentation - there seems to be more than 1 out 10 libraries similar!

It is possible that Apple moved the business logic from the OpenStep services into Carbonlib. The reason I suggest this is Obj-C applications can call extrernal methods that are linked either static or dynamic. C/C++ expects static only. Moving the business logic of, lets say NSArray, into CarbonLib makes it visible to both run-time environments.

Of course we have both been talking in absolutes. Most likely some libraries were moved into CarbonLib and some totally recreated.

Jove

PS.
I dropped a not so subtle hint that a condescending tone is not appropriate. We are all here to learn. If somebody has a misonception, such as the desktop being useless for everybody :), correct - don't preach.

 
There is nothing OpenStep-ish about the pasteboard or NetInfo or CoreGraphics. OpenStep merely provides an easy way to access OS X's "CoreServices" which are accessed by IPC calls not ObjC messages.

ObjC classes are just a nifty way to organize c stacks. The code doesn't care if they are in actuality a bunch of inline functions.

The CoreServices do not link to CarbonLib or AppKit for the most part, and for good reason. They are lightweight processes which provide basic services to various programs whether they link ro Carbon, Cocoa, or neither. The loginpanel.app for example doesn't use Cocoa or Carbon.

Quake 3 eventually won't use Carbon or Cocoa but will use OpenGL, HID, CoreAudio, sockets, and nothing else.

Cocoa and Carbon are bloated as heck and serve mainly as a convenience to us programmers to support the growing number of technologies like AppleScript.

Even in the old days when OPENSTEP used ObjC to write everything including drivers they didn't use stuff from foundation, it was a programmatic convenience.

The one exception is probably OPENSTEP 'Services'. Supporting them in Carbon may require TextEdit and WASTE to call a function in Cocoa, although probably looking up the SEL and calling the method directly.

(I only with Cocoa's text handling was less OPENSTEP-ish)
 
Hello,

So then, if I understand you correctly, the Obj-C run-time (messages) and its class libraries are wrappers around core services and etc? I was under the impression the messaging architecture went deeper.

How is Apple progressing creating a set of C++ classes to interact with or duplicate Foundation?

Jove

 
Strobe,
Are you still out there? My last questions were serious inquiries, not meant as jabs.

Jove
 
You must log in or register to reply here.
Back
Top