[gorgonzola]

I'm interested in programming for Mac OS X, and I've started with C. I've been using the Kernighan & Ritchie book (K&R), and I've finished everything *except* the following chapters:

* pointers (everything on pointers)
* structures
* multidimensional arrays
* lists, tables, typedef, that stuff

If you have the book (version 2), it's basically everything from the chapter on pointers on.

So basically I need to first finish learning this basic C stuff, and then learn how to write for Carbon. All the documentation I've found concerns taking an existing app and porting it. Yes, thanks, I know this is easy -- I don't want to bother learning any Classic programming if I can help it. I know there's a large overlap, but there are also differences, and I'd rather not bother with the Classic version of this thing.

Do you guys have any suggestions as to how I can learn Carbon given the stage I'm at? I know it'll take time; what I'm looking for is a book or something that will walk me through everything.

Any ideas? Much appreciated, thanks.

[00101001]

If you are starting your first app for OS X, then I sugest you skip Carbon alltogether and go with Cocoa. Objective-C is fairly easy to learn if you know C, plus, it is extremely poweful. Carbon is old news, apple is going to phase it out in a couple of years because it is still based on the old OS 9 crap. Cocoa is really the core API for OSX. So if you've got the Dev. tools, check out some of the tutorials included on objective-C, you'll be amazed at what you can do in minutes with Cocoa that would have taken HOURS trying to implement in Carbon.
(If you really want to use Carbon, sorry, i can't help)

[gorgonzola]

[edited]

OK, I'll go with Cocoa. I don't have a working knowledge of C yet, but once I do, what's the best way to go about learning Obj-C and then Cocoa?

------------------
the oddball newsletter
------------------
it's only after you lose everything that you're free to do anything

[This message has been edited by gorgonzola (edited 02-25-2001).]

[3.1416]

I strongly agree with 00101001 on this. If you're just starting out you will have a *much* easier time with Cocoa than Carbon. To use Carbon you have to get to a much lower level than Cocoa and constantly deal with pointers, memory allocation, and a bunch of other nasty stuff that Cocoa (mostly) takes care of automatically. To use either you will want a basic knowledge of C (actually Carbon would require more extensive knowledge), but don't be scared by Objective C's extensions; they're pretty easy to learn compared to the rest of C. I would skim the ObjC documentation (the most important concepts are objects and how to send messages to them) and then go through the simple Cocoa examples. I guarantee you'll be able to produce your first app much faster in Cocoa than Carbon. This isn't to say Carbon is bad, but its primary purpose is to be a compatibility library for existing Mac apps. For new development, Apple strongly encourages Cocoa.

[gorgonzola]

Originally posted by 3.1416:
I strongly agree with 00101001 on this. If you're just starting out you will have a *much* easier time with Cocoa than Carbon. To use Carbon you have to get to a much lower level than Cocoa and constantly deal with pointers, memory allocation, and a bunch of other nasty stuff that Cocoa (mostly) takes care of automatically. To use either you will want a basic knowledge of C (actually Carbon would require more extensive knowledge), but don't be scared by Objective C's extensions; they're pretty easy to learn compared to the rest of C. I would skim the ObjC documentation (the most important concepts are objects and how to send messages to them) and then go through the simple Cocoa examples. I guarantee you'll be able to produce your first app much faster in Cocoa than Carbon. This isn't to say Carbon is bad, but its primary purpose is to be a compatibility library for existing Mac apps. For new development, Apple strongly encourages Cocoa.

This is interesting. Let me list what I don't know in C yet:

* Arrays (anything having to do with arrays except the most basic stuff)
* Pointers (anything having to do with pointers)
* malloc/calloc/etc
* Structures
* All the ways in which the above 4 work together

This is basically all the important stuff in C, so to speak, because stuff like int x; declarations aren't really that complicated. This is the bulk of the difficult stuff in C.

I am planning on making myself familiar with all the parts of the C language itself before I move on to any kind of GUI programming.

So Cocoa allows you to bypass certain parts of nasty memory management? I wasn't aware. Also, Apple will probably have tons of documentation for beginning programmers in Cocoa but almost none for Carbon. Hm.

I think Cocoa is the way to go. So once I have a working knowledge of C, what should I do? Read the 200-page Obj-C book that Apple bundles with the dev tools and look through PB/IB examples?

It'll take two months, probably, to finish up C itself. Then I'd have to learn the extensions included in Obj-C (another few weeks), and then I can move onto Cocoa. What do you think is the best way of going about this?

thanks. any more information about cocoa that would interesting to a programmer (specifically, stuff it does for you) would also be useful. I know a bunch about Cocoa but not from a developer's perspective.

thanks again

------------------
the oddball newsletter
------------------
it's only after you lose everything that you're free to do anything

[Mniot]

A few tips:
Arrays: Skim it. Hopefully you won't need too many arrays, so you won't need huge in-depth knowledge
Pointers: Always useful. It's not as tricky as everyone says, but it does take some practice to be comfortable with them.
Malloc: Obj-C has some ways to make memory allocation less painful, but it would help to know how to do things the hard way first.
Structures: Here's where the object-oriented stuff kicks in, and you get to use classes instead. Read the Obj-C docs more than the C docs on this.

I hope you've got a computer (preferably with OSX on it) to practice one... That should really make learning more enjoyable. Also, there's no reason you have to follow a straight progression of C -> Obj-C. You might want to look at some of Apple's example apps to check out how much of it looks new, and how much you can do already...

[IamBob]

Okay, since this seems to be a fun lovin' group..

What's the best way to modify an existing C app (not my own) so it can be used from Obj-C? I guess, how do I turn it into a library and then use that in my app?

Is there a "Good Idea-Bad Idea" deal that I can use as a reference of what to do and what not to?

[typo]

[This message has been edited by IamBob (edited 02-25-2001).]

[gorgonzola]

Originally posted by Mniot:
A few tips:
Arrays: Skim it. Hopefully you won't need too many arrays, so you won't need huge in-depth knowledge
Pointers: Always useful. It's not as tricky as everyone says, but it does take some practice to be comfortable with them.
Malloc: Obj-C has some ways to make memory allocation less painful, but it would help to know how to do things the hard way first.
Structures: Here's where the object-oriented stuff kicks in, and you get to use classes instead. Read the Obj-C docs more than the C docs on this.

I hope you've got a computer (preferably with OSX on it) to practice one... That should really make learning more enjoyable. Also, there's no reason you have to follow a straight progression of C -> Obj-C. You might want to look at some of Apple's example apps to check out how much of it looks new, and how much you can do already...

I do indeed have a computer with OS X on it, but the Beta is now woefully inadequate for my needs and the appeal is wearing thin. The problem is that the Beta is fantastic for some things but nonfunctional for others (cough PRINTING cough). Such is the way with Betas, of course, but I can't really start things full-speed until I get the Final on my box and can work full-time in it.

I know that there's no specific reason to go C --> Obj-C, but I figure that since I've done half of C I might as well finish it. The first programming language is always the hardest, and if I get the basic concepts of the thing down pat then it'll stand me in good stead for a while. Once you understand pointers and arrays, for example, you can use those effectively in any other language. You just have to learn the few unique quirks. Plus, Obj-C is a superset, so many of the things (if not all) that I'd learn while doing C will be immediately usable in Obj-C.

I have Apple's 200 page book "Inside Cocoa" that basically describes Obj-C, OOP, and Cocoa. Looks good. Downloaded the currency converter PDF. I'm waiting for the Final and the Final dev tools because it's too much hassle to keep rebooting right now. I have to use OS 9 apps and print and stuff too often. =)

Plus, I figure that *everyone* will be learning Cocoa from scratch (except for Omni guys =) so there'll be a lot more beginner-level documentation out there.

thanks again

(IamBob, maybe I could help you in six months )

------------------
the oddball newsletter
------------------
it's only after you lose everything that you're free to do anything

[BigEndian]

I've finished everything *except* the following chapters:

* pointers (everything on pointers)
* structures
* multidimensional arrays
* lists, tables, typedef, that stuff

Another possibility is to look at programming in Cocoa-Java. The stuff you haven't learned yet is the stuff the Java generally takes care of for you (memory management, pointers).

I don't want to get into a discussion about which is better, Java or Obj-C, but Java is fairly easy to pick up especially if you already know a bit of C (I've been programming with Java for about three months and I've been able to produce some pretty solid Cocoa Apps with it). Plus, there are *way* more resources on Java than on Obj-C.

The only problem is that Java is a little slow in PB, but word on the street is that it will be much faster in Final.

[sadie]

As you say, the first language is the hardest. But there's one other detail: learning another language gives you a much better perspective on what you're doing, and why.

So once you've got Cocoa (however long that takes), try learning Cocoa-Java as an alternative. Using the same API will make it a lot smoother.

When it comes to learning C, you can skim through arrays (that are easy if you get pointers), structures (which become irrelevant in Obj-C) and typedef and stuff.

However, DO put the work in on pointers. I've heard it said that the ability to handle pointers is what separates a programmer from the rest of the world. Everything makes more sense if you know how memory allocation works - it's really fairly easy if you've got the brain space for it, but many people just haven't.

Knowing *any* C-derived language nowadays will make you employable - but you need pointers, or you're useless.

[gorgonzola]

Originally posted by sadie:
As you say, the first language is the hardest. But there's one other detail: learning another language gives you a much better perspective on what you're doing, and why.

So once you've got Cocoa (however long that takes), try learning Cocoa-Java as an alternative. Using the same API will make it a lot smoother.

/snip/

Knowing *any* C-derived language nowadays will make you employable - but you need pointers, or you're useless.

That's a good idea. I'll play it by ear after seeing the speed of Java under Final.

Guess I'll be spending a bunch of time on pointers...

------------------
the oddball newsletter
------------------
it's only after you lose everything that you're free to do anything

[IamBob]

Looks like I'll have my happy lil nose planted in print and pixels for a while.

[tea4u]

REALbasic is a wonderful environment. You can create commercial grade applications with it. Since it provides hooks for c++ plug-ins you can do amazing stuff if you are proficient in c++. However, Java and Obj-c are also powerful development environment. To some extent, implementing OS X apps with Java or Obj-c may be much easier than doing with REALbasic because of the Cocoa framework. I say 'environment' because these require you to learn their class libraries or frameworks that are not language itself.

What programming language to pick has always been provocative and often got anyone into holly war. But, I think choice of computer language does not automagically make a programmer good or bad. Anyone who can write efficient code in one language should be able to write quality code in another language.

There is an interesting article at Salon.com (http://www.salon.com/tech/col/garf/2001/01/08/bad_java/index.html). I don't know his credential and he seems to be biased a little bit. But he makes some valid point.

As someone said here, memory management as well as the generic algorithm are essential for programming regardless of language. I guess that's what you learn or are supposed to learn in CS classes for good. It's boring I know. So, using any language you like, you may want to start with a tiny 'hello world' project. That's good. But you should always come back to the basics.

Well, just my 0.02.

[parallax]

Yes, skip Carbon and go directly to Cocoa.

* Arrays (anything having to do with arrays except the most basic stuff)
* Pointers (anything having to do with pointers)
* malloc/calloc/etc
* Structures
* All the ways in which the above 4 work together

Arrays and pointers are inextricably tied, learn both of them and learn them well. malloc is simply allocating pointers to a fresh block of memory of your specified size e.g.

int *p;
p = malloc(sizeof(int)*4);
p[0] = 1;
p[1] = 2;
p[2] = 3;
p[3] = 4;

realloc makes new memory of the specified size, and copies the contents of the specified pointer (cutting off if the new size is smaller), and I believe freeing the old block.

calloc takes 2 arguments I think, but is essentially malloc initializing the memory to zero.

free obviously frees a block of memory.

Although you could use Objective-C's classes (classes are like structs, but with their own functions, and explicit support for inheritance), their run-time-ness makes things somewhat slow. Structs still have a lot of use. They do *not* become obsolete in any way.


Please don't use Realbasic. Obj-C and/or C is easy (and completely native).

[Dalgo]

Yea, I agree with Parallax. I wouldn't suggest a higher level language like real Basic. They are inefficient. Middle level languages like C and Objective C are good. I love Cocoa because it's so easy. It's easier than Carbon and... have you ever seen people use Windows API's to program windows programs? It's like 100 lines just to put a friggin window on the screen with a titlebar and stuff. It's evil. Objective C/Cocoa is the way that I'm going.

[gorgonzola]

Yes, I'm definitely not going RB -- I'm sticking with Cocoa.

thanks for the help

------------------
the oddball newsletter
------------------
it's only after you lose everything that you're free to do anything