[Maflynn]

Perhaps this has been bantered about before but why should I program using the Cocoa APIs over Carbons APIs.
I read some time ago that the makers of Realbasic were saying that carbon was just as good as cocoa. Can someone point me to a website that breaks down the differences, does cocoa have better memory management or thread processing?

Thanks
Mike

[Northform]

Carbon is as good as cocoa. The main advantage of cocoa is that it takes very little time to write an application in it. The main advantage of carbon is that you can also run carbon programs in earlier versions of the Mac OS.

One problem with carbon is that sometimes carbon apps don't work as well as cocoa apps. This has nothing to do with carbon being inferior, but rather developers who take the easy road in porting from classic and only rewrite the minimum ammount of code. IE 5.1 and Hotline 1.8.5 are good examples of this. Cocoa, since it requiries the app to be rewritten from scratch, ensures that the aqua interface, quartz, threading, etc. is all used properly. Cocoa doesn't have better memory management or threading than carbon; the difference is that carbon apps might not make full use of them if the developer didn't rewrite enough code.

RealBasic is confined by how well RealSoftware makes each version (the same applies to classic) but current versions seem to be very well done.

My advice: use cocoa for any new project because it requiries a lot less coding which not only means that it is easier to write an app, but there is also less chance of something going wrong (since there is less code to go wrong). Any exhisting apps I would continue to use carbon and make sure I did a good port.

[Chaaaosss]

I just realized this post answered none of your questions.

[ 05-04-2002: Message edited by: Chaaaosss ]

[kennethmac2000]

Originally posted by Northform:
<STRONG>RealBasic is confined by how well RealSoftware makes each version (the same applies to classic) but current versions seem to be very well done.</STRONG>

No they aren't. RealBasic UI elements are horrible in Mac OS X!

[ 05-04-2002: Message edited by: kennethmac2000 ]

[Smircle]

Originally posted by Maflynn:

Perhaps this has been bantered about before but why should I program using the Cocoa APIs over Carbons APIs.

It depends what you are aiming at. Cocoa is best used with Objective-C whereas Carbon ist best with C or C++. Obj-C is a Language that confines you to the Mac-platform, whereas C and C++ are industry-standard languages. Besides, some functionality you might want to use is available as open-source, but only when you use C++ (STL, boost...). So if you might want to port your apps and reuse your knowledge on other platforms then you might better off with C++/Carbon.

However, if you want to stick with MacOS, and if you do not care about the language then you might as well consider Cocoa.

[Angus_D]

I"m pretty sure we've had this discussion about 30 times already. Basically:
Cocoa - rapid development, Objective-C (a superset of C), limited to OS X (and possibly Linux/Win32 through GNUStep, but GNUStep is unfinished ).
Carbon - not so rapid development, more difficult to get an app that behaves as a "good OS X citizen", C or C++, runs on OS 8/9 too.

I wouldn't say that you have more code reusability with Carbon: if you want portability, write your core in C and then build the UIs on top of that.

[iJed]

I would just like to point out that you can easily mix Carbon and Cocoa calls in your app. It seems a common misconception that you have to stick to either one or the other.

[Maflynn]

From what I've been hearing and reading cocoa has no benefit functionality wise over carbon. It will allow you build applications faster if your starting from scratch, as long as you are familar with objective c. I was under the impression that cocoa had access to various methods and properties that carbon. As a hobbiest I'm not sure which side of the fence to land on, cocoa or carbon (using real basic.) I know C, a little C++ a good deal of Basic (I use VB on the pc).
One last question a prior post mentioned the plugins for real basic are not that good under osx. How does real basic stack up aganst VB. I realize its a different platform but as a user of vb I wonder how similar/different it is.

Thanks
Mike

[Angus_D]

Originally posted by iJed:
<STRONG>I would just like to point out that you can easily mix Carbon and Cocoa calls in your app. It seems a common misconception that you have to stick to either one or the other.</STRONG>

You can easily call Carbon from Cocoa, not the other way round.

Originally posted by Maflynn:
<STRONG>From what I've been hearing and reading cocoa has no benefit functionality wise over carbon.</STRONG>

That's the intention, yes. Although there are certain things missing from each, for example Carbon doesn't have drawers at the moment, and Cocoa doesn't have a global "hotkey" API. The idea is that they should be standardized, though.

<STRONG>As a hobbiest I'm not sure which side of the fence to land on, cocoa or carbon (using real basic.) I know C, a little C++ a good deal of Basic (I use VB on the pc). </STRONG>

I personally detest REALbasic, but that's just me (and a large portion of other people that I know, actually). It depends what you want. If you just want to do OS X, go with Cocoa. If you are familiar with VB and want to be able to cross-compile for classic and windows, go with RB. Note that RB isn't really Carbon, Carbon is an API... When you write programs with RB you're not directly writing to Carbon.

[iJed]

Originally posted by Angus_D:
<STRONG>
You can easily call Carbon from Cocoa, not the other way round.
</STRONG>

Maybe true for some of the Cocoa classes but not all. Classes like NSSound are easier to call from a Carbon app than their Carbon alternatives!

<STRONG>
I personally detest REALbasic, but that's just me (and a large portion of other people that I know, actually). It depends what you want. If you just want to do OS X, go with Cocoa. If you are familiar with VB and want to be able to cross-compile for classic and windows, go with RB. Note that RB isn't really Carbon, Carbon is an API... When you write programs with RB you're not directly writing to Carbon.</STRONG>

The REALbasic generated app is still pure CFM Carbon.

Having never really used REALbasic I often wonder why so many people hate it so much. The only reasons I can see (just from using REALbasic apps) is that the generated apps are much bigger than I would expect and sometimes quite slow. Other than that it looks really easy to use and perfect for novice developers.

[Glennfield]

RealBasic's OS X support seems to be rather flaky still... rather than use "real" OS X widgets, it uses its own ones which try, with varying success, to pretend to be the real ones. (Actually, this seems to be true of its Classic support as well... open up the resource fork of a RB app some time, and marvel at the PICT resources of checkboxes, buttons, and all the other GUI elements that the system should be able to provide on its own...)

If you want to develop quickly, RB may be the way to go - if you want to develop an app which really *feels* like an OS X app, stay far far away. (I have not developed in RB, but this is my impression based on every RB app I have used, including one in which I have had a fair bit of communication with the developer about the GUI issues.)

[Millennium]

Carbon can be as good as Cocoa. It depends on what you are trying to do, and how much effort you are willing to put into it.

Functionality-wise, Carbon still has a couple of gaps. However, these tend to be in areas which you might not even use anyway, most notably Drawers (if you never use them, then you'll never miss them).

Language-wise, things are nowhere near as bad when it comes to Cocoa as the Carbon-zealots claim. Note that the Cocoa-based port of Quake 3 to OSX -which is several million lines of code overall- uses only 800 lines of OSX-specific code. Not even 1% of your code has to be platform-specific, except perhaps in the most trivial of apps. Because Cocoa can be made to use Objective-C++, you can use most of the C++-specific stuff you've come to know and love, and you should still be able to call plain C++ and C libraries.

Carbon or Cocoa? Your call. But if you choose Carbon, you had better be willing to put in the effort to make a Good Carbon App; there are depressingly few of these out there today and you. If you don't know Classic's event model already, do not even learn it. Forget FSSpec unless you're in one of the extremely rare instances where you might need it; use FSRef instead. Learn HIDManager (which appears to be strongly based on Carbon Events) if you want to write games. And so on, and so forth. If you use text boxes, learn to work with Services (and curse Apple for not making Services support automatic for its standard controls).

[Northform]

Originally posted by kennethmac2000:
<STRONG>

No they aren't. RealBasic UI elements are horrible in Mac OS X!

[ 05-04-2002: Message edited by: kennethmac2000 ]</STRONG>

RB 4 creates the UI elements quite well (a lot of UI things need to be changed if you created the project for 9 initially), but that wasn't my point any way and I don't want to argue an opinion point &lt;offtopic&gt;(I say if you don't like it don't use it. Same goes if you're complaining about theMHz gap. If it bothers you buy a PC)&lt;/offtopic&gt;. I meant that the current versions of RealBasic are a dramatic improvement over RB 2 where apps created with it would lock up the system regularly.

[Northform]

Originally posted by Smircle:
<STRONG>Originally posted by Maflynn:

It depends what you are aiming at. Cocoa is best used with Objective-C whereas Carbon ist best with C or C++. Obj-C is a Language that confines you to the Mac-platform, whereas C and C++ are industry-standard languages. Besides, some functionality you might want to use is available as open-source, but only when you use C++ (STL, boost...). So if you might want to port your apps and reuse your knowledge on other platforms then you might better off with C++/Carbon.

However, if you want to stick with MacOS, and if you do not care about the language then you might as well consider Cocoa.</STRONG>

Since Obj-C is a superset of the C language, all C code is also Obj-C code (but not all Obj-C code is C code). Obj-C is comming along and you can now get it to compile for most unix systems (see gnustep).

[Northform]

Originally posted by Maflynn:
<STRONG>From what I've been hearing and reading cocoa has no benefit functionality wise over carbon. It will allow you build applications faster if your starting from scratch, as long as you are familar with objective c. I was under the impression that cocoa had access to various methods and properties that carbon. As a hobbiest I'm not sure which side of the fence to land on, cocoa or carbon (using real basic.) I know C, a little C++ a good deal of Basic (I use VB on the pc).
One last question a prior post mentioned the plugins for real basic are not that good under osx. How does real basic stack up aganst VB. I realize its a different platform but as a user of vb I wonder how similar/different it is.

Thanks
Mike</STRONG>

You cannot create an app in RealBasic and have it be a cocoa app.

I removed a comment about drawers that someone else already brought up.

[ 05-06-2002: Message edited by: Northform ]

[tobli]

Originally posted by Northform:
<STRONG>
You cannot create an app in RealBasic and have it be a cocoa app.
</STRONG>

I find this comment a bit strange. When you use RealBasic to develop an application the result will be a RealBasic application. To make use of the Cocoa APIs when you develop an app, develop it using Cocoa. You're stating the obvious. True, at the moment the RealBasic runtime on MacOS X probably mostly uses the Carbon APIs, under the hood, to interact with the OS, but that's an implementation detail. Also, with more and more functionality beeing moved to the CoreFoundation frameworks both Cocoa and Carbon (and potentially other development frameworks, like RB) will all be based on a common foundation.