MFC -> Cocoa

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Melodious Thunk - 23 Aug 2007 01:29 GMT

Are there any Cocoa programmers with an MFC background, who would care
to point a confused old-timer toward some advice (docs, tutorials,
design analysis) on shifting ones' paradigm?

A few years back I wrote some stuff in MFC w/Doc-View architecture,
extensive multithreading, & extensive use of OpenGL. Recently I
reacquired the intellectual property rights; and I'd like to port this
sucka to the Mac. But I'm having a difficult time absorbing Cocoa
documentation.

I haven't yet figured out:

- How model/view/controller maps to my app's needs (I don't mind
refactoring, but I still need help just in basic architecture under
Cocoa)

- How I might implement a shared memory-mapped file, readable by
multiple threads (my app's job is to display topography that changes
dynamically)

- How I might implement an OpenGL window who's rendering surface is
drawn by an outside process (but maybe that was an optimization only
needed under windows...)

- What exactly are the IPC options Apple implements/recommends/warns
may break ('case the doc's imply they're all frail!)

I admit I've only been stabbing at it for a short time*. So I'm
posting quite prematurely into my project, hoping that a few old-
timers have walked this path before, and would lend a shoulder "to
this old arthritic hand." Thanks in advance. Bless ya', sonny!

· - heh, and I hate to admit it under 'da circumstances; but I was a
Mac programmer, '85 through '94. Right about when Windows NT came out,
I stopped writing Mac code (THEY paid me better). NOW, having not
touched Mac code for 13 years, I feel completely LOST! Where's my
Bento Box? Where's my global &qd? Why can't I still WaitForButton()?
What happened to my cherished Pascal calling conventions?

And what happened to my beloved OpenTransport? ;-)

Reply to this Message

Michael Ash - 23 Aug 2007 05:00 GMT

> I haven't yet figured out:
>
> - How model/view/controller maps to my app's needs (I don't mind
> refactoring, but I still need help just in basic architecture under
> Cocoa)

You've probably seen this already, but in case you haven't:

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/Coco
aDesignPatterns/chapter_5_section_4.html

And in case you aren't familiar, the short version is that you split your
application into three parts, with two of them being reusable at least in
theory:

1) Model. These are the classes which actually hold and manipulate data.
Examples in Cocoa would be NSDictionary, NSAttributedString,
NSTextStorage, etc. They should be reusable, so that you can take your Foo
model from one app and use it to have Foos in a different app.

2) View. These are the classes which display the interface and allow user
interaction. Examples in Cocoa are all NSView descendants, including
NSControl descendants. They should also be reusable, so that if you have a
view which can display Bars in one app, you can use it to display Bars in
another.

3) Controller. These are the classes which connect the Model to the View.
They hold application-specific logic. Examples in Cocoa would be the whole
NSController hierarchy, although Cocoa is much weaker in this area simply
because controllers tend to be app-specific. These are not generally
reusable, since they're the entities which know that your app has a Baz
menu which should take the current selection in your Bar view and apply it
to the Foo model.

Strict MVC separation can be really difficult to obtain and can be
restrictive, but it's a good principle to follow in general.

> - How I might implement a shared memory-mapped file, readable by
> multiple threads (my app's job is to display topography that changes
> dynamically)

NSData has file mapping capabilities which you could probably use.
Otherwise you can use the POSIX function mmap().

> - How I might implement an OpenGL window who's rendering surface is
> drawn by an outside process (but maybe that was an optimization only
> needed under windows...)

Can't be done, find another way. OpenGL contexts and windows have very
strict per-process separation in OS X.

> - What exactly are the IPC options Apple implements/recommends/warns
> may break ('case the doc's imply they're all frail!)

For communicating with a subprocess you execute, my favorite is good old
pipe(), accessible in Cocoa through NSPipe and NSTask. They're simple
(just read and write data to a file descriptor), fast, and integrate well
with the system. Other options include shared memory (extremely dangerous,
doable with mmap()), mach ports (somewhat arcane but very light weight),
TCP/IP (overly complicated for local use), Apple Events (godawful slow and
ridiculously complicated but integrates well with the Mac view of
applications), and Cocoa Distributed Objects (technically a protocol which
you layer over something else, almost always mach ports, but it deserves a
separate mention because it's so common and extremely cool).

> ? - heh, and I hate to admit it under 'da circumstances; but I was a
> Mac programmer, '85 through '94. Right about when Windows NT came out,
> I stopped writing Mac code (THEY paid me better). NOW, having not
> touched Mac code for 13 years, I feel completely LOST! Where's my
> Bento Box? Where's my global &qd? Why can't I still WaitForButton()?
> What happened to my cherished Pascal calling conventions?

I know that you're joking but Cocoa actually has no real heritage from the
old Mac stuff; it comes from NeXT, which followed a pretty different API
path. Of course there is also Carbon which is directly descended from the
old Mac stuff but you'll probably find a great deal of that changed beyond
recognition too.

> And what happened to my beloved OpenTransport? ;-)

It's still there, in stunted form, as a compatibility layer in Carbon. I
do not recommend using it, though: BSD sockets are the native API and, in
any case, are much better. :)

Signature

Michael Ash
Rogue Amoeba Software

Reply to this Message

Melodious Thunk - 23 Aug 2007 16:58 GMT

> > I haven't yet figured out:
>
[quoted text clipped - 82 lines]
> Michael Ash
> Rogue Amoeba Software

Thanks for the detailed response, your info helps enormously.

Reply to this Message

Mac Forum / Programming / Mac Programming / August 2007

MFC -> Cocoa