Recommend Carbon Programming Books ?
Lou Pecora
with good (but not excellent) C++ knowledge, who has dabbled in some OS9
API stuff and wants to continue dabbling with Carbon? I really just
want a few things: File Navigation, some keyboard event capturing, and
plotting/simple drawing in a window. I do numerical/scientific
programming and will not be doing extensive GUI work.
I checked Learning Carbon (by Apple) and Carbon Programming (by
Bricknell), but neither gets what I'd call a strong endorsement in the
reader reviews. Is there something else?
Thanks.
-- Lou Pecora (my views are my own)
Daniel T.
Lou Pecora <pec...@anvil.nrl.navy.mil> wrote:
<http://www.mactech.com/macintosh-c/> is a great book, and is on-line.
Lou Pecora
"Daniel T." <postm...@earthlink.net> wrote:
> <http://www.mactech.com/macintosh-c/> is a great book, and is on-line.
Thanks.
Jan E. Schotsman
> >
> > I checked Learning Carbon (by Apple) and Carbon Programming (by
> > Bricknell), but neither gets what I'd call a strong endorsement in the
> > reader reviews. Is there something else?
>
> <http://www.mactech.com/macintosh-c/> is a great book, and is on-line.
That is the book by Bricknell and it is fast become obsolete. No Quartz, no
HIView, etc. etc.
Learning by doing is the best way. Search newsgroups, headers, documentation,
mailing lists, Apple sample code. Ask questions in developer forums. Get used
to the fact you can't find it all in one place.
Jan.
M. Uli Kusterer
"Jan E. Schotsman" <j_e_sc...@compuserve.com> wrote:
> Learning by doing is the best way. Search newsgroups, headers, documentation,
> mailing lists, Apple sample code. Ask questions in developer forums. Get used
> to the fact you can't find it all in one place.
I don't want to start an API war, but just to be complete:
Remember that you can also use one of the other APIs besides (or in
addition to) Carbon on MacOS X. There are some projects where you're
better off using Carbon (e.g. low-level file system tools, background
daemons, contextual menu modules), but for most other tasks (especially
involving GUIs) it's usually easier to use Cocoa on a Mac these days (in
particular, C++ integrates beautifully with Objective C, so your
cross-platform codebase can come along, and ObjC is about five simple
extensions on top of straight C).
If you want more info, say so. I'm stopping here in case you already
knew that.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
Lou Pecora
> Apple sample code.
That may be the most helpful. Thanks.
But it does sound like time for "Carbon: The Missing Manual"
Lou Pecora
"M. Uli Kusterer" <wit...@t-online.de> wrote:
> If you want more info, say so. I'm stopping here in case you already
> knew that.
No, I didn't know that. I have no knowledge of Obj-C. Say more or just
point in the right direction. Thank you.
M. Uli Kusterer
Lou Pecora <pec...@anvil.nrl.navy.mil> wrote:
> In article <witness-5D5EEC...@news.t-online.com>,
> "M. Uli Kusterer" <wit...@t-online.de> wrote:
>
> > If you want more info, say so. I'm stopping here in case you already
> > knew that.
>
> No, I didn't know that. I have no knowledge of Obj-C. Say more or just
> point in the right direction. Thank you.
Well, basically you'll want to get Aaron Hillegass' book on MacOS X
programming (2nd edition). He describes most of the stuff you need to
know to get started with Cocoa and Objective C if you know the basics of
straight C.
To give you an idea how easy the stuff is: I read through that book in
one day, doing the examples as I went along, and wrote my first own
Cocoa application the day after. Where Cocoa really shines is GUI
design, as you can simply use Interface Builder to instantiate views,
windows and menus per drag and drop, and even connect them so they know
about each other, which saves you all that GetNThControlInWindow() stuff
(that's still there if you need it, though). You can even instantiate
non-GUI classes in that file. It's basically the logical evolution of
ResEdit and PowerPlant Constructor.
ObjC is only a few extensions on top of C, and the language is a lot
simpler than C++, while offering you about the same power (basically,
for ObjC you have to learn a different syntax for calling methods,
declaring classes and instantiating classes, and you have protocols and
categories with a syntax analogous to a class declaration, and that's
it).
It's a straight superset of C (more so than C++, which changes a few
things), and thus integrating C code with Cocoa is no work at all. If
you want to use C++ with Cocoa, you change the suffix of your source
file to ".mm" instead of ".m", which switches the compiler to "Objective
C++", which basically means the Objective C compiler uses C++ instead of
C as its basis. Objective C++ lets you mix and match C++ and ObjC
expressions in one source file, even on a single line, as separate
operands in an expression.
They are still two distinct languages, and an ObjC object is different
from a C++ object, but since it's easy to wrap an ObjC object in a C++
object or the other way round [1] you'll usually not notice.
And Cocoa's consistent adherence to the "Model-View-Controller" pattern
means it's easy to keep your portable model and model-controller in C++
STL, POSIX or StdCLib, without the rest needing to know about it.
Also, since MacOS X 10.2, you can mix and match Carbon and Cocoa. Since
Carbon is a C API, that's been possible before in a limited way, but now
you can have a Carbon window in a Cocoa app (having a Carbon control in
a Cocoa window isn't yet possible, though. So, if you need to create a
hard disk toolkit, you can use the Carbon HFS APIs for lightning-fast
low-level access, and use Cocoa for everything else. [2]
Unless you're deploying to 10.1 or earlier, it's not *either* Carbon
*or* Cocoa. It should IMHO be both of them, usually with a Cocoa app
that takes advantage of Carbon when needed.
Just my $0.02,
-- M. Uli Kusterer
http://www.zathras.de
[1]: Just know that you can't have an actual C++ object as an instance
variable in an ObjC object. You can, however, have a pointer to one as
an instance variable and use "new" to allocate that in the ObjC object's
constructor, so that isn't really a problem.
[2]: My TADS 3 compiler ("Workbench") was written around the portable
TADS C++ core, once in Carbon, and a second time in Cocoa. I thought
doing it in Carbon would be easier. I was wrong. The C++ code happily
calls back into ObjC and vice versa. And it's not much work to wrap that
one delicious Carbon API that may be needed forthat special app in an
ObjC class, since most new Carbon APIs these days work with
pseudo-objects like CoreFoundation, and thus easily map to an OO
language like ObjC.
Lou Pecora
"M. Uli Kusterer" <wit...@t-online.de> wrote:
> > No, I didn't know that. I have no knowledge of Obj-C. Say more or just
> > point in the right direction. Thank you.
>
> Well, basically you'll want to get Aaron Hillegass' book on MacOS X
> programming (2nd edition). He describes most of the stuff you need to
> know to get started with Cocoa and Objective C if you know the basics of
> straight C.
[cut much good info]
Thanks very much. A very nice overview!