• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: Charles Srstka <email@hidden>
  • Date: Sun, 27 Jan 2002 04:39:08 -0600

On Sunday, January 27, 2002, at 03:52 AM, David Niemeijer wrote:

Ok, so how is Carbon easily accessible from 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?

AFAIK, most of the Carbon calls are C functions, so you should be able to call them from any C variant, which includes all the above. You will need to include Carbon.framework in your project, and you will need to put #include (or #import) <Carbon/Carbon.h> at the top of your code.

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?

I'm not the expert on this, but it should be completely possible.

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?

Don't know the answer to this one.

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?

Couldn't you just implement a bunch of methods in an object, each of which called some function in your Carbon core, and wire the interface elements to the methods?

Other issues for us are:

1) How integrated multiprocessing and threading are in Cocoa?

Well, you have to use Distributed Objects if you want to do AppKit stuff in the threads, since AppKit isn't thread-safe. If your threads just do grunt-work, threading is pretty easy.

2) How integrated AppleScript is in Cocoa?

Very. AppleScript Studio itself is really nothing more than a Cocoa app with no Obj-C objects in it. Any Cocoa app can do anything AppleScript Studio can do, AFAIK.

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).

Someone else will have to answer this...


  • Follow-Ups:
    • Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
      • From: David Remahl <email@hidden>
References: 
 >Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?) (From: David Niemeijer <email@hidden>)

  • Prev by Date: Re: Sample code - building an Apple Event in a Cocoa application?
  • Next by Date: Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
  • Previous by thread: Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
  • Next by thread: Re: [LONG] Making the right choice (was Re: How viable is Cocoa development?)
  • Index(es):
    • Date
    • Thread