I've been doing iPhone development full-time over the last couple of months.
Having previous experience only in OOP, I've relied heavily on Apple's APIs, which eventhough majestic I must reckon, led me to write code that in retrospective looks like a weird mix of ruby/smalltalk with added boilerplate.
So I'm thinking I'm missing out, and ordering K&R. Yet I wonder how what I'll learn, can specifically be put to good use in iOS work, without fighting against the devices' API and the whole OO pardadigm ?
The lower level APIs are largley in straight C, perhaps you'd like to explore them? For example Quartz 2D has a C API.
Objective-C is a superset of C. You can intermingle Objective-C and C function calls, statements, etc.
So for example, if you prefer Posix sockets to NSSocketPort, you can just mix in the C socket functions wherever you want. Or, if you wanted to keep it a little more object oriented, you could wrap C statements in an Objective-C function call that would isolate your C code from the rest of your Objective-C code.
Something that might help you understand the relationship between C and Objective-C would be to create an Objective-C wrapper for some C code. I’d recommend writing a simple iPhone app scripted in Lua. That should be enough of a project to really look at the C.
Not learning C is not missing out on anything.
I almost agree with #jeff except that I don't see why so many beginning Objective C programmers go straight for the iPhone stuff when they could be running a Mac app with much less hassle and convert it later.
But yes, buying a copy of K&R would be a very good idea (as well as getting a copy of the C90 or C99 standards, if you can afford them). In fact, I have a book on iOS games that suggests going straight to vanilla C for a lot of the low-level stuff to cut out the messaging overhead for performance's sake. Essentially, you're not doing anything you're not "supposed" to do by using C functions; the C library is still there to be used, so you aren't doing anything particularly strange or kludgy.
Related
I believe the question speaks for itself, and I know that to many of you this question might seem retarded. I just wonder if everything, in Objective-C, that starts with Core is written in a plain C.
My guess is "Yes, it is.", but I want to be sure for 100% ;)
Many thanks.
EDIT: Looking at the answers I now realise I should have asked about the syntax in Core libraries.
Is it always C like syntax: void myFunction(int num); and not - (void) myFunction:(int) path;?
So far one thing that I am not too fond of, in Obj-C, is mixing ()/dot/-> syntax with [] syntax. I think it really isn't elegant...
No offense, but the proper answer is "who cares"? (insert tongue in cheek)
Honestly, though, any system libraries can be written in pretty much whatever they want. There's probably a combination of Objective-C, C, C++, and assembler; less likely (but technically still possible) options include Pascal, Fortran, LOGO, or hand-assembled machine code.
If you want an example of the combinations of code in system libraries, take a look at the open-sourced Java libraries. You will see that the java.* packages are written in a combination of Java and C; some ports may include assembly for parts.
As long as the interface is Objective-C compatible, that's all you really need to worry about.
Also, the only people who can answer that are probably at Apple, and probably aren't allowed to tell you.
It's written in "whatever" (a bit of ObjC, a lot of C, a bit of asm), but the key thing is that the interface it presents is pure C.
I'll note that Core Data and Core Image present ObjC interfaces though.
Yep it is - Appkit / UIKit is built on top of that, and they've done some tricks to make the interaction between ObjC and Core* to be very efficient (called "Toll-free Bridging")
It is Objective-C after all; the language is a very small layer of syntax on top of straight C with a runtime library to provide the dynamic behaviors.
Mixing C and Objective-C is a very oft encountered and natural part of the environment.
As others have said, the languages used to implement the various Core* frameworks is an implementation detail that should generally be of no concern. With that said, a good sized and growing chunk of CoreFoundation is written in Objective-C.
I'm planning to learn Objective C. Most of the books say that the reader should know C as a starting point.
Is it necessary to know C before diving in the Objective-C ocean ? I'm a ruby programmer.
I personally think you should be fine diving in without C. Yes, Objective-C is a superset of C, but that doesn't that all Objective-C coding will require C knowledge. The situation is similar for C++. I say if you have a firm knowledge of at least one programming language and know the basics of C's constructs and syntax you should be fine to start the other stuff. You don't need to be able to write strong C applications before you get started with Obj-C, but it will help you a lot once you can.
If you find you need to do something that requires deeper C-knowledge, then you can hit the C manual a bit harder, but it probably isn't necessary until you get to that point. You should be able to develop your experience of the two languages pretty simultaneously instead of having to learn C for a month before you can even touch Objective-C. :D
Here's what the Objective-C books want you to know about C:
typing system. Pointers, arrays, structs
functions.
general design and organization of programs.
Since you're a ruby programmer, most of this should come fairly easily. The biggest shock is going to be moving from a high-level dynamic language to a low-level static language, so be prepared for some big changes, buts its nothing you won't be able to handle.
From Wikipedia -
Objective-C is a reflective, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. Objective-C is a thin layer on top of C, and moreover is a strict superset of C;
Yes , you should have knowledge of C.
As #arjan points out it's a superset of C. You might be able to work your way though examples and such without prior C experience, however to become productive you will eventually have to understand plain C. For examples many APIs such as SQLite access are only C (not ObjC/Cocoa). You really have to grasp concepts such as pointers, C-style strings etc.
You can't program in Objective-C without knowing C, as Objective-C is simply a superset of C.
I don't think it is absolutely necessary, I learnt Objective C with no knowledge of any other languages. However, saying that, it is very useful if you know C and a bit easier.
Nah. As long as you know what functions are, variables, objects, then you'll pick up "C" syntax by programming in objective C. To be more specific, I don't think you need to go and "learn C" first. Rather, I'd keep a C reference handy and look up anything you don't understand there.
I want to build a plugin for an application(TeamSpeak), however I have no lua knowledge. Is it possible to somehow wrap or bridge my Obj-C knowledge to lua?
If needed I could learn the basic syntax of lua to get my plugin started, but ultimately I want the meat of the program in Obj-C.
Any advice appreciated!
Lua's api written in c so rather than going from obj-c to Lua, you will have to go from obj-c to c to Lua. This is not as bad as it sounds though, obj-c and c play well together so you can have functions to expose to Lua in your .m source files and/or use .c source files in your project. As far as I know there isn't a luabind type library for obj-c but if you are using c++ with your obj-c this may also be an option.
Once you get past the stack manipulation, you will probably find the api pretty intuitive. The c api for tables can be a little confusing at first but it is also extremely powerful and allows you to expose your application's functions in many interesting ways.
Lua is a fairly simple, yet extremely powerful language. For example, there is only one datastructure: tables. Unless you are trying to do complex things with metatables you can probably dive right in with little trouble coming from Objective C. Do note that array indices (i.e. tables with sequential numerical keys) are 1-based instead of 0-based. Take a look at Programming in Lua (PiL) to get started.
Search for iPhone Wax on Google. Might not be what you need, but might help your needs. It lets you call Obj-C via Lua.
Well, I think I have enough knowledge of cocoa that I can go learn another thing. What would you recommend learning after learning cocoa? (Ex. Core animation, OpenCL, core data)
I really depends what your goals are. If you want to stick to Objective-C, dive into Cocoa Touch if you haven't already. I'd also suggest checking out frameworks such as MacRuby if you want to stick to developing Mac apps, it is pretty sweet.
If you want to go somewhere totally different, I've been messing around with Rails and Android a lot recently.
Learn LISP.
It is fundamentally different from pretty much every other programming language there is. It will force you to think of problems in new ways. Even if you never ever will use LISP in a real world project (I never did) you will become a much better programmer.
Anyone who wants to call themselves a programmer should known about (spent at least a full week with):
C - to know the heavy lifting and how it actually works.
LISP - to understand functional programming.
Smalltalk/Objective-C - to understand real object oriented programming.
Prolog - to understand logic programming.
C++, and any language that derives its OOP design from it, is just C structs with function pointers. Yes Java and C# I look at you too.
Learning PostScript is a good way to broaden your understanding of the drawing model also used by Quartz and AppKit, and can be useful for prototyping your drawing code.
Learn another language. Maybe C/C++ since they are similar. Or maybe C#. Or you can try something completely different such as python, pascal, D or VB.
depends what you aim for
but if you are not strong in C/C++ I would suggest that. A) its what cocoa is based on B) if you want to port your code to other platforms, usually you'll have a good chance of reusing directly the C/C++ withou a lot of changes.
(Ex. Core animation, OpenCL, core
data)
those are just tools, if you want to specialize in iphone then its good practice to look up the various feature, look at the examples and then implement a little example for yourself.
otherwise if you have no precise goal you can also go to the bookstore and pick a random book ^^
I've become very comfortable in the world of pointer-free, garbage-collected programming languages. Now I have to write a small Mac component. I've been learning Objective-C, but as I confront the possibility of dangling pointers and the need to manage retain counts, I feel disheartened.
I know that Objective-C now has garbage collection but this only works with Leopard. My component must work with Tiger, too.
I need to access some Cocoa libraries not available to Java, so that rules out my usual weapon of choice.
What are my alternatives? Especially with no explicit pointers and automatic garbage collection.
What do you mean by "component?" Do you mean a chunk of code or a library you are going to hand to other people to link into their apps? If so then it is not realistic to use any of the bridged languages at this time. While a lot of the bridges are very nice, they almost always have complications and issues that most app developers will not be willing to deal with to use a single component, especially if it involves bringing in a substantial runtime.
The bridges are most valuable to bridge other language libraries into your Objective C app. While you can write fairly complete apps using them, doing so often requires a better understanding of Objective C than simply writing an Objective C application, since you need to understand and cope with the language, object model, threading, and memory allocation impedance mismatches that occur.
This is also why many people argue that even if you are quite familiar with a language, trying to learn Cocoa using that language through a bridge is generally more difficult that learning it using Objective C.
Finally, much of the recent support for bridged languages was due to "BridgeSupport," a feature was added in Leopard. Even bridges that predate that have been migrating towards, sometimes in such a way that using the bridged language on Tiger and Leopard can have substantial differences. Also, there is currently no bridge support for iPhone, and most bridged languages will not work on it, if that is an issue.
Ultimately, if you are writing a library that is going to be linked into other apps, you need to run on Tiger and Leopard, and you need to access Cocoa only APIs I think you will find using any non-Objective C solution quite difficult.
You can try PyObjC to write Cocoa apps in python, or MacRuby if you are interested in Ruby.
You shouldn't be intimidated by Cocoa's retain/release reference counting. It's much, much easier in practice than GC fans would have you believe. The Cocoa memory management rules are dead simple, they only affect a tiny amount of your code, and even that code can be generated automagically.
Here's the trick. You encapsulate your MM code in accessor methods, and always use accessors. Xcode has built-in scripts to generate the appropriate accessors, or if you need more flexibility there are 3rd-part apps like Accessorizer.
This isn't an intrusive approach - you only need to worry about retaining an object if you're going to need to keep it for later use, and if you're going to do that you'll need an instance variable in which to keep it anyway. And, if you're using KVO and bindings, you'll need to use accessors to make sure the appropriate observer notifications are fired. Basically, if you're using good OOP and Cocoa practices, there's practically no additional thought or effort involved with memory management.
Most folks who have difficulty with Cocoa's "manual" memory management are doing so as a result of misusing it. The most common mistake is to scatter the relevant code all over the place. That means that a missing retain, extra release, etc will be difficult to find.
Try any of the Cocoa bridges listed in here http://www.cocoadev.com/index.pl?CocoaBridges
You can also try F-Script - a smalltalk dialect that is written specifically for MacOSX/Cocoa.
RubyCocoa is getting steadily more impressive, and I've seen lots of successful implementations using it. That is, of course, if Ruby's your cup of tea...
You can always use REALbasic (www.realsoftware.com). Real easy and fun to use, not free though. You can not make dylibs (or dll's) using it, but you can use dylibs and dll's in your code. And you can use cocoa libraries as well
Don't forget that you can use java as well, and i don't mean java-cocoa bridge, i mean actual java.
There's also a package from apple that provides you with access to a couple of osx features as well.
Also to comment on Shem's point, if your targeting osx 10.5 and above, you can take advantage of garbage collection.
If you want lisp syntax then Nu is a lisp implemented on top of Objective-C http://www.programming.nu/
Also, FreePascal can generate native Carbon Apps (in progress working for Coccoa)
Look at Python and wxPython (the wxWidgets in Python).
The wxWidgets have a very elegant App-Doc-View application design pattern that's very, very nice. It's not used enough, IMO. I haven't found any wxPython examples of this App-Doc-View example, so you have to use the C examples to reason out how it would work in Python.
I'd post examples, but I haven't got it all working yet, either.
.NET via Mono mono-project.com
See NObjective (http://code.google.com/p/objcmapper/) bridge to Cocoa. It provides more features than others with less overheads.
I'm looking into Mono too. Objective-C is a little too bizarre for me at this point. Too many years doing C/C++, Java, C#, Perl etc. I suppose. All these seem pretty easy to float between. Not so for Objective-C. Love my Mac but afraid it will take too much precious time to master the language.