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: Stefan Jung <email@hidden>
- Date: Sun, 27 Jan 2002 12:44:46 +0100
Am Sonntag den, 27. Januar 2002, um 10:52, schrieb David Niemeijer:
Ok, so how is Carbon easily accessible from Cocoa?
Write your function call as you would do without Cocoa.
1) Can I call Carbon from an Obj-C, Obj-C++, C, or C++ file that is
part of a Cocoa application? If so, what special steps need to be taken?
Most of Carbon is C and Cocoa is 100% ObjC. ObjC is 100% C plus objects.
So this 100% compatible. If you have data and want a Carbon function to
do something with it, let it do, you will get back whatever the Carbon
call returns. If you want to use C++ you can do that in parallel with
two files. You can also put C++ and ObjC code into the same file using
ObjC++; in this case you can also mix C++ and ObjC code, that means
access member functions form an ObjC object or call a method form
within a C++ object. Of course the syntax for an ObjC method call
remains the same regard from were it is called and vice versa.
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?
Of course. All Carbon funtions are shared libraries. The Carbon
framework is linked in by default.
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?
If the data types are toll free bridged, like CFStringRef and NSString *
you only have to do a cast. In other cases it depends...
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?
Some data conversions are surely necessary. Exchanging projects via XML
(have no experience here) should be possible. Mixing binaries...I don't
no if there are traps with mixing CFM and Mach-o code.
5) Did I forget an important question on this issue...
Other issues for us are:
1) How integrated multiprocessing and threading are in Cocoa?
Multiprocessing is done automatically if you have more than one
processor AND you have threaded your apps. The operating system can not
make arbitrary threads out of your monolithic app.
2) How integrated AppleScript is in Cocoa?
I think at least half way MacOS 9.
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).
There is a general performance penalty when using objects, a bit more
with ObjC's runtime engine, but very probably it won't harm your app.
When you read in a file you have to make objects out of the raw data.
This can be done via Cocoa's archiving/encoding mechanism or you have do
it on your, at least it has to be done. Of course if your files do not
contain any objects, then here is no difference.
David.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
Stefan Jung