Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
- Subject: Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
- From: Kurt Revis <email@hidden>
- Date: Sun, 27 Jan 2002 03:27:46 -0800
Here's a quick answer to your questions... someone correct me if I'm
wrong about any of this. (I know I'm glossing over a lot of details.)
1) Can I call Carbon from an Obj-C, Obj-C++, C, or C++ file that is
part of a Cocoa application
Yes.
If so, what special steps need to be taken?
Nothing, just call whatever Carbon functions you like. There really is
nothing to it when accessing low-level Carbon functionality. Displaying
Carbon UI controls, or interacting with the Carbon event loop, is much
more difficult (and depending on what you're doing it may be
impossible) -- but you don't typically need to do this in Cocoa.
2) Can I, from a cocoa application, easily access a plug-in or shared
library containing Carbon based code? If so, what special steps need to
be taken?
If the Carbon plugin uses CFBundle or CFPlugIn, or if it's just a plain
old shared library, this will work pretty easily and should not be a
problem. But again, it depends on what the plugin or shared lib is
doing. It will be running in a Cocoa app, so if it tries to use Carbon
to display UI, it will have problems.
(If the shared lib or plugin is CFM, you will have to do some work to
use it from a Mach-O application; Apple has documentation about this.
Also, CodeWarrior's C++ compiler mangles symbol names differently than
gcc does, as far as I know, so you may run into linking issues with C++.)
3) Can I easily share Cocoa Foundation Framework objects with
"equivalent" Carbon Core Foundation objects, i.e. pass them along
between Cocoa and Carbon code? If so, what special steps need to be
taken?
CoreFoundation is CoreFoundation. There isn't a separate "Cocoa" and
"Carbon" implementation. So you can pass objects back and forth without
doing anything. (In fact, many Cocoa objects are really CoreFoundation
objects--look up "toll-free bridging" in the release notes.)
4) How easy or difficult is it to put a Cocoa front-end (i.e. User
Interface) on a Carbon based core? Would everything have to be done in
PB or could the Carbon core be done in CW and "exported" to PB/Cocoa?
This really is highly dependent on what exactly you're doing. Obviously
it would be much simpler to build everything within PB, but I imagine
you could make some sort of dual-build system work. I don't know why
anyone would bother, unless the performance boost from the CW compiler
was absolutely necessary.
1) How integrated multiprocessing and threading are in Cocoa?
Certainly a lot more pleasant to deal with than Carbon. Why don't you
read the documentation and find out exactly what you need to know?
2) How integrated AppleScript is in Cocoa?
I am no expert at this stuff--I still find the Carbon scripting APIs
insanely complicated and badly documented--but Cocoa has some wrappers
on top of it that appear to be very easy to use. And you can always go
down and use the Carbon APIs if you need to, so the overall situation is
an improvement.
3) How large the speed penalty under Cocoa is when working with
extremely large files and large numbers of objects (instead of plain
data records/structs).
Once again, this depends on exactly what you're doing. I can't just say
"13.5% slower"! As with any API, some things are slow, some things are
fast, and you really need to do some profiling to see where to spend
time optimizing in your particular application. Coding naively in Cocoa
can be slow, but there are plenty of ways to speed things up in the 1%
of your code that is likely to be a problem. For instance, see this
article:
http://www.mulle-kybernetik.com/artikel/Optimization/opti-4.html
Also note that there is absolutely nothing stopping you from using plain
old C techniques. In many cases this is the best approach.
Hope this helps. There really is nothing to be afraid of.
--
Kurt Revis
email@hidden