I am relatively proficient in Objective-C but I have been looking around some frameworks and libraries I might use in the future and I am increasingly seeing the use of C. So far the only applications I have written contain only Objective-C. I know Objective-C is a superset of C, but what I mean when I say that I have only written in Objective-C is that I have only used Objective-C methods and the syntax of Objective-C that is distinctly different from C syntax. I've been going through questions related to the relationship between C and Objective-C (see links below) and I want to start learning C, but apparently there are three types of C (K&R, C89, and C99), and I am wondering which type I should learn to help me with Objective-C. I know from learning Objective-C I unknowingly learned C too, but I want to understand the ins and outs of C more and become familiar with its functions, syntax, features, etc. Also, is Objective-C based off of any one of the three types of C?
There are even more types of C. In the meantime C0X and C11 were defined... They all make only small evolutionary steps from their predecessors, so you shouldn't worry much about it. Objective-C is based on C99 (minus floating point pragmas, actually), so for now that would probably be the best fit.
It's not entirely clear from your question, but you do notice that those variations of C are just evolving specifications from different years? K&R from ca. 1978, C89 from 1989, C99 from 1999 etc... Objective-C was designed to be a strict superset of C, so you can probably expect Objective-C to incorporate C11 features some day.
(NB: several edits to include information from the comments)
I suggest you look at some introductory texts on C, and learn whatever C dialect the text teaches. This will likely be C89 or C99.
K&R C is missing modern features such as "prototypes" (declaring the number and types of arguments to your functions). C89 adds all that stuff in.
C99 has, mostly, small incremental features that are useful in specific domains. The bulk of the stuff you need to learn should be identical across C89 and C99. Fun fact: Microsoft never bothered to implement C99.
Actually, I will suggest a specific introductory text: use the Second Edition of K&R. This basically updates K&R to C89. K&R is an outstanding book, and a great choice for learning the C language.
https://stackoverflow.com/questions/1646667/kr-1st-edition-vs-2nd-edition
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'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.
I was wondering what I needed to know in terms of C to move onto Objective-C. I would be uber-grateful if you could let me know what you think is sufficient to move on Objective-C.
Thanks,
~Daniel
If you're looking to learn C before moving on to Objective-C (which, in my opinion, is a great idea), I would recommend to you Steve Kochan's 'Programming in Objective-C 2.0'. Very similar to his 'Programming in C' book, it will contain all the C you're going to need to use Objective-C, and it's a great primer for learning both languages.
If you're not looking to read a book, though, or you already have one, I would assume that after learning pointers, you will have covered most of the important parts of the C language (of course, it will depend on the order of material in the book, but pointers are usually sufficiently advanced to move on). Good luck!
You need a book. "Programming in Objective-C 2.0" is a fairly good one, and there are a few others. It's not a bad idea to have two or three.
You need to understand basic pointer concepts. C or C++ is the way to go for that.
You need to understand basic object-oriented concepts. Objective-C is a poor platform on which to learn them, so you may want to first learn basic OO concepts on C++ or Java first.
Once you get started with Objective-C, you need to learn the screwy syntax, of course, and all about the UI concepts, but, more importantly, you need to really, REALLY understand and "internalize" the Objective-C heap management scheme. Java gives you no hint of this, C++ is a poor background, Qt is a hair better, but still pretty far off the mark, so pretty much you have to pick it up as you learn Objective-C.
Yes, we have a lot of kids here that have learned how to take an Objective-C example, modify a few lines, and produce an "app", without actually understanding what they are doing. But learning that way they're never going to be able to produce anything of consequence. You need to INVEST in learning, not simply "pick it up as you go".
Personally I would suggest you learn C++ so that you can master the concept of polymorphism, which is pretty important in objective C and iPhone programming. Since you already know C I think that this would be better than jumping from C to objective C.
I recently asked a question on switching from C++ to C for writing an interpreter for speed and I got a comment from someone asking why on earth I would switch to C for that.
So I found out that I actually don't know why - except that C++ object oriented system has a much higher abstraction and therefore is slower.
Why are the interpreters of all popular scripting languages written in C and not in C++?
If you want to tell me about some other language where the interpreter for it isn't in C, please replace all occurences of popular scripting languages in this question with Ruby, Python, Perl and PHP.
C is a very old language, and is thus supported on pretty much every system available. It is therefore a good choice for any project that needs to be ported everywhere.
Ruby dates back to 1995. If you were writing an interpreter in 1995, what were your options? Java was released in the same year. (And was painfully slow in v1.0 and in many ways, not really worth using)
C++ was not yet standardized, and compiler support for it was very sketchy. (it had also not yet made the transition to the "modern C++" that we use today. I think the STL was proposed for standardization around this time as well. It didn't actually get added to the standard until years later. And even after it was added, it took several more years for 1) compilers to catch up, and 2) people to get used to this generic programming style. Back then, C++ was an OOP language first and foremost, and in many cases, that style of C++ was quite a bit slower than C. (In modern C++ code, that performance difference is pretty much eliminated, partly through better compilers, and partly through better coding styles, less reliance on OOP constructs and more on templates and generic programming)
Python was started in 1991. Perl is even older (1987)
PHP is from 1995 as well, but additionally, and importantly, was created by a guy who knew virtually nothing of programming. (and yes, of course this has shaped the language in many important ways)
The languages you mention were started in C because C was the best bet for a portable, future-proof platform back then.
And while I haven't looked this up, I'm willing to bet that apart from the PHP case, which is shaped by incompetence more than anything, the language designers of the other languages chose C because they *already knew it. So perhaps the lesson is not "C is best", but "the language you already know is best"
There are other reasons why C is often chosen:
experience and accessibility: C is a simple language that is fairly easy to pick up, lowering the barrier of entry. It's also popular, and there are a lot of experienced C programmers around. One reason why these languages have become popular might just be that it was easy to find programmers to help developing the interpreters. C++ is more complex to learn and use well. Today, that might not be so much of a problem, but 10 or 15 years ago?
interoperability: Most languages communicate through C interfaces. Since your fancy new language is going to rely on components written in other languages (especially in early versions when the language itself is limited and has few libraries), it's always nice and simple to call a C function.So since we're going to have some C code anyway, it might be tempting to go all the way and just write the whole thing in C.
performance: C doesn't get in your way much. It doesn't magically make your code fast, but it allows you to achieve good performance. So does C++, of course, or many other languages. But it's true for C as well.
portability: Practically every platform has a C compiler. Until recently, C++ compilers were much more hit and miss.
These reasons don't mean that C is in fact a superior language for writing interpreters (or for anything else), they simply explain some of the motivations that have caused others to write in C.
I'd guess it's because C is pretty much the only language that has a reasonably standard compiler for almost every platform in existence.
I would hazard a guess that it's in part due to 1998 C++ not being standardized until 1998, making achieving portability that much harder.
All those languages you list were developed before that standardization.
Why are the interpreters of all popular scripting languages written in C and not in C++?
What makes you think that they are written in C? In my experience, the majority of implementations for the majority of scripting languages are written in languages other than C.
Here's a couple of examples:
Ruby
BlueRuby: written in ABAP
HotRuby: JavaScript
Red Sun: ActionScript
SmallRuby: Smalltalk/X
MagLev: Ruby, GemStone Smalltalk
Smalltalk.rb: Smalltalk
Alumina: Smalltalk
Cardinal: PIR, NQP, PGE
RubyGoLightly: Go
YARI: Io
JRuby: Java
XRuby: Java
Microsoft IronRuby: C#
the original IronRuby by Wilco Bauwer: C#
Ruby.NET: C#
NETRuby: C#
MacRuby: Objective-C
Rubinius: Ruby, C++
MetaRuby: Ruby
RubyVM: Ruby
Python
IronPython: C#
Jython: Java
Pynie: PIR, NQP, PGE
PyPy: Python, RPython
PHP
P8: Java
Quercus: Java
Phalanger: C#
Perl6
Rakudo: Perl6, PIR, NQP, PGE
Pugs: Haskell
Sprixel: JavaScript
v6.pm: Perl5
Elf: CommonLisp
JavaScript
Narcissus: JavaScript
Ejacs: ELisp
Jint: C#
IronJS: F#
Rhino: Java
Mascara (ECMAScript Harmony Reference Implementation): Python
ECMAScript 4 Reference Implementation: Standard ML
The HotSpot JVM is written in C++, the Animorphic Smalltalk VM (from which HotSpot and V8 are derived) is written in C++, the Self VM (on which the Animorphic Smalltalk VM is based) is written in C++.
Interestingly enough, in many of the above cases, the implementations that are not written in C, are actually faster than the ones written in C.
As an example of two implementations that are written in C, take Lua and CPython. In both cases, they are actually written in a small subset of a very old version of C. The reason for this is that they want to be highly portable. CPython, for example, runs on platform for which a C++ compiler doesn't even exist. Also, Perl was written in 1989, CPython in 1990, Lua in 1993, SpiderMonkey in 1995. C++ wasn't standardized until 1998.
The complexity of C++ is great compared to that of C - many people consider it one of the most complex and error prone languages in existance.
Many of the features of C++ are problematic as well - the STL was standardized many years ago and it still lacks one great implementation.
OOP is certainly great, but it does not outweigh C++'s deficiencies in many scenarios.
Most known compiler books are written with examples in C.
Also two of the major tools lexx (builds a lexer) and yacc (Translates a grammar to C) have support for C.
If the question is about why C and not C++ the answer comes down to the fact that when you implement a scripting language the C++ object model comes into your way. Its so restricted that you will not be able to use it for your own objects.
So you can only use this for the internals and they there you usually do not get enough benefits from C++ over the much simpler C language, which makes it easier to port and distribute.
The only problem when implementing a script language in C are missing coroutine support (you have to switch your stack pointer in some way) and most important there is no way to do exception handling without a lot of overhead (compared to C++).