I know several programming languages including Objective-C, Java, C#, and python, and C. However, I need to brush up my efficiency in C.
In most languages that happen to be high-level, object-based, and GUI-oriented, I create a few standard object-oriented examples to orient me to the language/framework. I usually create a "car" example where I model a car and allow the user to adjust the speed, watching the mileage increase.
However, something tells me this example is not as practical to carry over to C in a unix command-line setting. What are some good basic ideas to 'test myself' in a unix command-line based C setting?
Thanks for any input!
EDIT:
Thanks for the answers. My basic concern with the car example is that I shouldn't be attempting object-oriented in this environment, but rather do something that is more suited to the language. Thanks to Duck for the suggestion of recreating command line utilities.
Get yourself a copy of
C Programming Language (2nd Edition)
Recreate (for the umpteenth time) any of the standard command line utilities - cat, ls, touch, more, less, etc. Write a basic shell. These will exercise C and re-familiarize you with unix system calls.
try this: http://www.gowrikumar.com/c/
They provide puzzles and problems, have you spot them, and then you can check your answer. Might not be enough for what you asked for, but it might be a start?
You can write something similar with structures. Create a car structure and create functions that operate on the Car structure passed as a pointer (explicit this parameter). You can use conio.h or ncurses.h to do fancy console animation using timers. This can be fun and may provide some insight. You will also need to read keyboard input to increase/decrease speed.
Get "Advanced Programming in the Unix Environment" by W. Richard Stevens. The lectures and examples in this book are much more in tune, more realistic and practical to the type of work that is done in C. They show you the intent and purpose (and to a high the degree the philosophy) of the language.
That, IMO, will be better for brushing up your C (in addition to revisiting the oldie-but-goldie K&R book.)
I strongly recommend you go this route (in particular if you are coming from a UI, object-oriented world.) One world of caution: Do not try to do OO in C. It can be done, but that is not your immediate purpose. Learn how to code and model procedurally in C (in particular with examples tuned to its intended purpose.)
It seems to be an 'accepted concept' in the popular culture of programming languages that 'C is portable assembler'. I have first heard this at least 15 years ago. But when did it really become part of the popular culture?
Note: if you don't agree that 'C is portable assembler', please just skip this question. This question is about 'popular culture of programming'. I'll add a comment to this question which you can up-vote for those who disagree with that statement.
From the Introduction to the first edition of The C Programming Language:
C is a relatively "low level"
language. This characterization is not
pejorative; it simply means that C
deals with the same sort of objects
that most computers do, namely
characters, numbers, and addresses.
[ ... ]
Again, because the language reflects the capabilities of current computers, C programs tend to be efficient enough that there is no compulsion to write assembly language instead.
[ ... ]
Although C matches the capabilities of many computers, it is independent of any particular machine architecture, and so with a little care it is easy to write "portable" programs ...
At least the general idea of combining portability with the general capabilities of assembly language seems to have been there almost from the beginning.
That was why C was developed. From the very, very beginning, C was designed for portability.
The concept of C being "portable assembler" stems for the simple fact that most "pop-culture level" C programmers are too lazy to learn the language "hard" - academic - way, and instead prefer to "learn" from practice, in most part by associating the language commands with the implied underlying machine code. Most of these associations are based on rather ridiculous misconceptions about the language, which latter surface here (and on other forums) as questions along the lines of "I have 20 years of experience in C programming but I don't understand why my type-punning hack no longer works". Nevertheless, most of those "portable assembler" types actually take pride in their approach, considering everybody else not sufficiently competent to see assembly behind the C code :)
In other words, the only people who see C as portable assembler are the people who never bothered to learn the language. It is indeed just a pop-culture. C is not a portable assembler, and it is not really a matter of "agreeing" or "disagreeing" with it, but rather a matter of knowing it as a hard fact. The "popular culture of programming" you seem to be mentioning has very little connection with the professional C programming world.
My guess would be the first time that there was a higher level language than C.
That would make C portable, but still fairly low level (and at least in some minds, the closest you can get to Assembler and still be portable).
The moment they started extrapolating/ misinterpreting definitions of words :)
Assembly language: symbolic representation (a.k.a. mnemonics) of the numeric machine codes and other constants needed to program a particular CPU architecture.
Assembler: A program to convert assembly language into machine language.
C: A programming language which
(1) is not a mnemonic of a particular CPU architecture
(2) cannot be fed into an assembler
P.S:Feel free to downvote this answer as much as you want :)
Based on recommendations from episode 57 of the StackOverflow Podcast, I have purchased "Structure and Interpretation of Computer Programs", "The C Programming Language", "Unix Programming Environment", and "Introduction to Algorithms". I'm wanting to improve my fundamental programming skills, contribute to some open source projects, and improve my future employment prospects. Is there a suggested reading order for the selected texts? Also, what particular subjects/sections from the books should I pay more attention to? Thanks.
If you already have a programming background you could get use from Cormen et al quite early. I found the audio lectures at http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-046JFall-2005/CourseHome/ helpful to go with it and you might also want to read the syllabus and prerequisites.
If you need more programming then either the C book or SICP can be used. I learnt C first and came to SICP later. I was happy with that approach -- I can't say which would suit you. The C book can just be worked through sequentially.
UPE probably needs a reasonable C background to get the best from it, though it has value for all programmers.
I'm not sure how much these help to increase earnings but I enjoyed them all and was a better programmer and IT professional for working at them
I'm sure others will have different and perhaps better, at least for them and perhaps for you, suggestions.
I've read these books except the Unix Programming Environment.
The C Programming Language (white book) is a good book to learn C.
Structure and Interpretation of Computer Programs (SICP), is a special kind of book. It's a book that you really have to study. It will teach you many programming concepts.
The three first parts of the book are a must read.
Building Abstractions with Procedures.
Building Abstractions with Data.
Modularity, Objects and State.
Introduction to Algorithms is a bit hard for self-learning but a good book.
I don't think you should study the books in any particular order. The important is to not skip the exercises.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Being an aspiring Apple developer, I want to get the opinions of the community if it is better to learn C first before moving into Objective-C and ultimately the Cocoa Framework?
My gut says learn C, which will give me a good foundation.
I would learn C first. I learned C (and did a lot in C) before moving to Obj-C. I have many colleagues who never were real C programmers, they started with Obj-C and learned only as much C as necessary.
Every now and then I see how they solve a problem entirely in Obj-C, sometimes resulting in a very clumsy solutions. Usually I then replace some Obj-C code with pure C code (after all you can mix them as much as you like, the content of an Obj-C method can be entirely, pure C code). Without any intention to insult any Obj-C programmer, there are solutions that are very elegant in Obj-C, these are solutions that just work (and look) a lot better thanks to objects (OOP programming can make complex programs much more lovely than functional programming; polymorphism for example is a brilliant feature)... and I really like Obj-C (much more than C++! I hate the C++ syntax and some language features are plain overkill and lead to bad development patterns IMHO); however, when I sometimes re-write Obj-C code of my colleagues (and I really only do so, if I think this is absolutely necessary), the resulting code is usually 50% smaller, needs only 25% of the memory it used before and is about 400% faster at runtime.
What I'm trying to say here: Every language has its pros and cons. C has pros and cons and so does Obj-C. However, the really great feature of Obj-C (that's why I even like it more than Java) is that you can jump to plain C at will and back again. Why this is such a great feature? Because just like Obj-C fixes many of the cons of pure C, pure C can fix some of the cons of Obj-C. If you mix them together you'll receive a very powerful team.
If you only learn Obj-C and have no idea of C or only know the very basics of it and never tried how elegantly it can solve some common problems, you actually learned only half of Obj-C. C is a fundamental part of Obj-C. The ability to use C at any time and everywhere is a fundamental feature of it.
A typical example was some code we used that had to encode data in base64, but we could not use an external library for that (no OpenSSL lib). We used a base64 encoder, entirely written using Cocoa classes. It was working okay, but when we made it encode 200 MB of binary data, it took an eternity and the memory overhead was unacceptable. I replaced it with a tiny, ultra compact base64 encoder written entirely as one C function (I copied the function body into the method body, method took NSData as input and returned NSString as output, however inside the function everything was C). The C encoder was so much more compact, it beat the pure Cocoa encoder by the factor 8 in speed and the memory overhead was also much less. Encoding/Decoding data, playing around with bits and similar low level tasks are just the strong points of C.
Another example was some UI code that drew a lot of graphs. For storing the data necessary to paint the graphs, we used NSArray's. Actually NSMutableArray's, since the graph was animated. Result: Very slow graph animation. We replaced all NSArray's with normal C arrays, objects with structs (after all graph coordinate information is nothing you must have in objects), enumerator access with simple for loops and started moving data between the arrays with memcopy instead of taking data from one array to the other one, index for index. The result: A speed up by the factor 4. The graph animated smoothly, even on older PPC systems.
The weakness of C is that every more complex program gets ugly in the long run. Keeping C applications readable, extensible and manageable demands a lot of discipline of a programmer. Many projects fail because this discipline is missing. Obj-C makes it easy for you to structure your application using classes, inheritance, protocols and so on. That said, I would not use pure C functionality across the borders of a method unless necessary. I prefer to keep all code in an Objective-C app within the method of an object; everything else defeats the purpose of an OO application. However within the method I sometimes use pure C exclusively.
You can readily enough learn C and Objective-C at the same time -- there's certainly no need to learn the minutiae of C (including pointer arithmetic and so on) before starting with Objective-C's additions to the language, and as a novice programmer getting underway with Objective-C quickly may help you to start "thinking in objects" more quickly.
In terms of available resources, Apple's documentation does typically assume familiarity with C, so starting with The Objective-C 2.0 Programming Language won't be of much benefit to you. I would invest in a copy of Programming in Objective-C by Stephen Kochan (depending on how quickly you want to get underway, you may consider waiting for the second edition):
Programming Objective-C Developers Library
Programming Objective-C 2.0 Developers Library
It assumes no prior experience, and teaches you Objective-C and as much C as you need.
If you're feeling a little ambitious, you might start with Scott Stevenson's "Learn C" Tutorial, but it does have some prerequisites ("You should already know at least one scripting or programming language, including functions, variables and loops. You'll also need to type commands into the Mac OS X Terminal.").
(Just for the record and for context: I learned both at the same time back in 1991 -- it didn't seem to do me any harm. I did, though, have a background in BASIC, Pascal, Logo, and LISP.)
I thought a lot about this issue before writing my book on Objective-C. First, I really believe that learning the C language before learning Objective-C is the wrong path. C is a procedural language containing many features that are not necessary for programming in Objective-C, especially at the novice level. In fact, resorting to some of these features goes against the grain of adhering to a good object-oriented programming methodology. It’s also not a good idea to teach all the details of a procedural language (and attacking a problem's solution with functions and structured programming techniques) before learning an object-oriented one. This can start the programmer off in the wrong direction potentially leading to developing the wrong orientation and mindset for fostering a good object-oriented programming discipline. Just because Objective-C is an extension to the C language doesn’t mean you have to learn C first!
I think that teaching Objective-C and the underlying C language as a single integrated language is the right approach. There's no reason to learn that a "for" statement is from the C language and not from its superset Objective-C language. Further, why learn in detail about things like C arrays and strings (and manipulating them) before learning about array (NSArray) and string objects (NSString), for example? Many C texts devote a lot of time to structures, and pointers to structures, and iterating through arrays with pointers. But you can start writing Objective-C programs without knowing about any of these C language features. And for a novice programmer, that's a big deal. Not only does that shorten the learning curve but also reduces the amount of material that has to be learned (and some of it selectively filtered out) to writing Objective-C programs.
I do agree that you will want to learn most, if not all, of the underlying C features, but many can be deferred until a solid grasp of defining classes and methods, working with objects and message expressions, and understanding the concepts of inheritance and polymorphism are well-understood.
I'd dive right in with Objective C - if you've already got a few languages under your belt, it's not the syntax which is the learning curve, it's Cocoa.
I think that, for the most part, learning C is a good idea no matter what arena you're going in to, at least to get the hang of the inner workings of software development before using prepackaged goods, that way if something goes wrong you have a better chance of understanding the inner workings. There's plenty of discussion about this on SO, and it's a rather subjective question, but in general you will inherently be using C within your Objective-C code, so I guess it's really up to you. I'm a ground up kind of person, but sometimes it can get in the way and I know several smart people who worked their way from the top down, I think the important part is that you get to understanding the inner workings as it will set your capabilities apart from those who don't as well as increase your capabilities.
It's a good idea to learn C before learning Objective-C, which is a strict superset of C. This means that Objective-C can support all normal C code, so the code common to C programs is bound to show up even in Objective-C code.
In addition to looking at things purely from a language point of view, you will find that Mac OS X is a complete Unix operating system. All the system level libraries are written in C.
It is probably possible to learn both at the same time, but I think you will appreciate and understand Objective-C more if you have a solid working knowledge of C first.
I'd learn Objective-C and learn as much C as you need as you go along.
The areas of C that you won't depend on much:
Pointer arithmetic and arrays. I haven't used C arrays at all.
C strings. Objective-C's strings do the job nicer and safer.
Manual memory management if you use GC in Obj-C 2.1. I highly recommend this route for development speed and performance reasons.
As you learn Objective-C and Cocoa, you cannot avoid learning bits of C. For example, rectangles are common represented by CGRect, a C struct.
If you have time, by all means learn C. As others have said here, Kochan's book (second and first editions) is excellent as a book to dip into.
There are a lot of things you can't do purely in Objective-C, so learning some basic C skills will be pretty critical. You'll at least need to understand variable declarations and the basic C library functions, or you'll be frustrated.
Honestly, so many languages are based on the C syntax that it's a good thing to be familiar with. I'd take a week or two to familiarize yourself with C regardless.
That said, I did just teach myself Objective C, and I have to be honest: I didn't find my C experience to be as useful as I would have thought. Objective C was definitely eye-opening for me.
You can jump directly into Objective-C, with the following benefits:
You'll learn "some" C in the way.
You'll learn the C parts that are relevant for you .
At least for me is easier to learn a new language when I'm interested in some specific app or sample, and I fail when I have to learn other thing that is not exactly what I'm interested on.
You can always refine your C knowledge later if you get interested in lower level programming.
Better, I don't know, even less as I am not familiar with Objective-C.
But bases of C aren't so hard to learn, it isn't a very complex language (in terms of syntax, not in terms of mastering!), so go for it, it won't be wasted time.
Personally, I think it is always a good idea to learn C, it gives a good insight of how computer works. After all, most languages and systems are still written in C. Then move on! :-)
PS.: By "move on", I didn't mean "drop it", just "learn more, learn different". Once you know C, you might never drop it: Java uses JNI to call C routines for low level stuff, Python, Lua, etc. are often extended with C code (Lua reference even just assumes some C knowledge for some functions which are just a thin wrapper to the C function behind), and so on.
Yes, learning C language before any other advanced langauges will help you to learn quiclky other langauges.
According to Wikipedia, Objective-C is a strict super-set of C. This being the case, I would suggest learning C first. Then when you learn Objective-C it will be clear what parts are added as part of Objective-C.
C gives you very little abstraction from assembly. Some C Compilers will even let you inline assembly. This can be very useful for thinking about how the computer works, which is important to know.
That being said, if you're really interested in Object-C don't let yourself get stuck writing something in C just because its "good for you". You don't need to frustrate yourself while you're trying to learn a new skill set. It is important that you have fun with what you're doing.
Do you want to be a hard-core developer? Then learn c first.
The books you need to completely master c are some of the best writings in technology. Here's what you need:
C Programming Language
The Standard C Library
Objective C is sufficiently different from C as to not merit learning C first.
From a syntax / language-family perspective one is almost better off studying SmallTalk (on which objective C is based)
From a practical perspective, focus your efforts on learning one language at a time.
Later, if you wish to learn another language, C++, Java and Python are 1) easy to learn as a bunch 2) popular and thus marketable 3) powerful.
You should have a basic knowledge of C before starting Objective_C, but there's no need master every detail of C.
I've published my notes after reading "Programming in Objective-C" in case it helps someone else.
learn objective c with programming-
Depending on many languages you already know it may be a better idea to just start learning Objective-C. The foundation in most languages are basically the same, it's the syntax that is different. Learning C first isn't really going to make much of a difference when it comes to learning Objective-C.
I learned Objective-C straight away and it worked fine for about a year now, I just had some difficulty reading C code when I downloaded project to see how they work, but now I really feel the need to learn C. You can try learning ObjC without C, but sooner or later, you will need C.
IMHO one should first learn at least some C and especially about pointers. That’s even more important if one comes from a language that doesn’t have pointers. A lot of people ask about code like
NSString *string = [[NSString alloc] init];
string = #"something";
since they don’t know about the distinction between a pointer and the object it points to.
Of course one doesn’t have to learn all of C before one can start with Objective-C, but some fundamental things are absolutely necessary.
Heck no, go straight to objective C!
I moved from ActionScript 3 to Objective C, and I already have an intern at a company!
Do what you want.
If you learn some other language prior, then you will always have confusion in writing right syntax. I do not know purpose, but Object C uses weird (not common) syntax for calling object methods. It names it as sending messages, yes, it is true accordingly pure Object Oriented concept, however most Object oriented languages name that as calling method and use more traditional syntax of calling methods. Garbage collection is also something very odd, Object C is based on old school reference count. So you will have difficulties to accept it if you switch from other language.
I am writing a book Object C quick migration guide for C/C++ programmers hoping to help people to pickup all differences quicker.