Slashdot Mirror
C
Lost in the Company of Giants
It's hard not to take a book like C and compare it to such acclaimed and trusted books as K&R, Expert C Programming, and other lesser known, but equally good tomes. Unfortunately C doesn't really compare with many of the other classic books covering the C language. For starters, the writing in this book isn't quite up to the same caliber as the other books. Part of the problem with this book is language. English does not appear to be the author's native language. There are sentences in this book that require a few glances to glean the full meaning. C is difficult enough to present without a language barrier introducing more problems. Another problem is organization. The ideas presented at the beginning of the book are muddled and disjointed, with multiple ideas introduced but not formally explained until later. Beginners will have a terrible time working through this book without becoming quickly confused, and experienced programmers will likely pass on this book in favor of the other well-known books.
Not All Bad
The book is not all bad, however. The examples in the book are plentiful and are based on tried-and-true examples found in books like K&R. There are some idioms that are used in the examples that will irk the more structured programmers (not using braces in certain areas being the biggest example), but most of the examples are pretty good. Also, the explanations of the more advanced topics are relatively good considering how confusing the more basic material is. Memory management is explained well, with clear diagrams (although the programs are a bit confusing without a careful eye).
So What's in it for Me?
Addison-Wesley is clearly marketing this book to the same crowd that purchases quick-learning books. Unfortunately beginners purchasing this book will quickly find themselves lost amid the confusing descriptions in this book. Those who manage to muddle through will find some tasty bits of information locked inside, but the work involved in getting there outweighs the rewards. Most programmers will probably want to leaf through a copy of this book before purchasing it to make sure they'll get the most out of it.
You can purchase C from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
I was just getting into C programming (specifically for a project on my Palm, but also in general using GCC like for my GBA and Linux)... And I was looking for a good C book the other day but wasn't sure (there are quite a few). I'm an experience programmer in Java and other languages, so I don't need a basic tutorial on how C works.
What I need is a book that talks about how to use C in real projects. Gochyas, how to use the STL, etc. Also, I don't really feel like using C++ which seems like too much - even though it's more similar to Java - it looks like the vast majority of apps that I want to explore and use are written just in C...
Any suggestions?
-Russ
Me
Experienced programmers usually use man if my collegues and I are any example.
man is good as a specific reference but I think since you are already an experienced programmer you aren't looking for a book like this one.
K&R and "Advanced C Programming By Example" by John Perry.
If you are reading this discussion because you are planning to learn C, know that not only is K&R's book a very fine book, but there is geek cachet in being able to say "I learned C from Kernighan and Ritchie".
Not to sound arrogant, but this statement belies a need for substantial reading about C and C++, not casual reading.
One of my CS profs (Georgia Tech people probably know who I'm referring to) gave the class advice on buying a C book: Flip through the book. If malloc isn't covered, put it back. If malloc is covered in an appendix, put it back. If the book contains the line cp=realloc(cp,n); then "burn it! Burn it right there in the store! Burn all of them!"
Actually, "C" is about dead-on average, I'd say!
markIf you want to make an apple pie from scratch, you must first create the universe. -- Carl Sagan
Learning C as your first language, without any prior computer experience may not be the most clever thing to do. Programming C efficiently, correctly and clearly is best achieved by first understanding computer architecture and programming concepts.
A higher level language provides the abstractions necessary to accommodate "logical thinking" as opposed to a full understanding of say memory management and system I/O. Also, C is quite an orthogonal language in that it supports many awkward combinations of features and constructs. If you are not careful to make your source text clear and readable, debugging even your own code can be oh so cumbersome.
Hence, perhaps reading a book such as "Computer Architecture: A quantitative Approach" by J. Hennessy and D. Paterson is a sensible step towards learning C for the beginner.
Because it only came out in 1995.
Also, old does not necessarily mean bad; universities still teach LISP (out in 1958) and quite rightly so.
It seems that Dennis Ritchie was so besotted with A and B that he forgot to take out the trash.
If the computing industry had any sense, it would have switched to Java 10 years ago. Why hadn't it? Inertia!
Speaking of taking out the trash...I prefer to say when garbage collection occurs. I don't get that control with Java like I do with C.
The best book for C beginners I've ever come
across is _A Book on C_, by Al Kelley,
and Ira Pohl. I've recommended it to quite a
few beginners and they've all said it was an
easy and very informative read.
"A man talking sense to himself is no madder than a man talking nonsense not to himself."
As an example, I can recall a man who came into the store where I was working, and who asked me how much "virtual memory" cost.
Besides trying not to laugh there was the problem mentioned above.
The fundamental concepts missing were the concepts of "memory" and "virtual", along with a larger mental model to enable the average person to organise the concepts into something useful when dealing with computers. [The usual mental model I use for beginners is one of a computer = your information factory. Hard drives = warehouse, etc.]
It is possible to arrange things inthe manner of " Gradus ad Parnassum " (graded steps)
Without proper technique in this area, It is very easy to make a bloody mess of it. It is a skill in its own right, separate from knowledge of the area to be taught in the first place.
"It is a greater offense to steal men's labor, than their clothes"
When you walk into HQ or Home Depot have you ever asked yourself why are there so many tools that do about the same job? There is always the right tool for the job. This is the same as it is in the programing world. I have heard people in this thread say why use C. Because if its the right tool to get the job done then use it. Don't get so caught up in one language, even a new one, that you make yourself a dino.
A good C book is always a great find. I find myself going through kernel code or drivers or as of late the netsnmp code going hmmm.. I've seen this before but exactly what is going on.
Refrence material is always good..no matter what.
What I would love to see is a thread on what books most coders have found to be the most useful, what they have on there shelves.
I love reading the reviews that say the book is good but not really worth my time.
If I were only smart enough to accomplish the things I dream about.. Or maybe too dumb to care.
C has no bounded array support. This makes it inherently unsuitable for any security programming taks.
*cough* *NIX is written in C *cough*
Yes, but wasn't Windows also originally written in C? I guess it's the programmers and not the language that determine the security.
From the jargon file:
C is a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language.
I'm confused now
I guess I'll wait for "D" to come out
If an experiment works, something has gone wrong.
So what you're saying is that you prefer a language that has NO MEMORY MANAGEMENT to one that does?
A good programmer can manage memory without the help of the runtime environment. There's a certain pride in being able to program with no memory leaks.
An old april-fools joke, this snippet will give you a good chuckle at the expense of C:
% 2))P("| "+(*u/4)%2);
"We stopped when we got a clean compile on the following syntax:
for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+*u++/8)
To think that modern programmers would try to use a language that allowed such a statement was beyond our comprehension!"
Also check out shooting yourself in the foot in various programming languages.
--
Disclaimer: The above statement probably includes half-truths, because real truth is too complicated.
Not only that, but pulling a dog-eared, bookmarked, highlighted copy of K&R off your bookshelf has the panty-removing power of playing your band's seven inches or flashing the keys to your '57 Corvette.
If it ain't broke, you need more software.
Reasons to still use C (at least sometimes):
1. It is the native language to most operating systems API (*nix, MS-*).
2. It is the language most third party librarys and code is written in.
3. It is the language a lot of old code is written in.
4. Interfacing other languages with libraries or APIs written for C is never as easy as the documentation says it is and issues may slow down development time significantly.
5. It is the only widely used standardized all purpose language that is available to all platforms.
C++ - is hardly standardized (most compilers still does not come close to the ANSI-C++ standard).
ADA - Is not widely used.(unfortunately)
Java - Is not an all purpose language.
6. It is a very elegeant and consistent language (unlike C++).
What makes you think dynamic memory management in C is efficent?
Just because "malloc" and "free" each fit on one line of code doesn't mean they are fast or efficient. In particular, if your memory arena gets seriously fragmented, the performance of these routines can get worse and worse over time.
As opposed to a genuine generational garbage collector, for which the performance stays relatively consistent.
Then where have all the good programmers gone? Or have they all moved over to Lisp?
- UNIX Systems Programming for SVR4
Not only does it addtess such cryptic issues as UNIX terminals and processes in great detail, but it also covers much of the C standard library. A must have for any serious C programmer.Storing the __LINE__ and __FILE__ compiler variables along with each allocation in your debug build, and being able to print the current state of all allocations is a no brainer. And it points to exactly the point of leakage. For a more complex project, add tags so you can check for memory of a given type left between points in your code.
You should get the idea, and adapting this to suit your memory usage mode should be pretty straightforward.
A decent programmer should be able to add this to his project and find all leaks between reading this and going home tonight. RAM leaks are a sign of a bad programmer, or a programmer too lazy to create good tools for himself.
Quit blaming your tools. Get off your ass and make the ones you're missing.
I am really curious as to know peoples opinions on Ada. It is highly verbose and slightly annoying but overall the system seems well thought out. Class-wide programming seems straightforward enough and the compiler seems to catch just about everything that would cause cryptic C++ bugs. It takes a little longer because quick and dirty hacks aren't allowed, but overall it seems very good.
But that would mean they would have to understand what there doing! All they underlying hardware is just a pain, and the certianly don't want to be bothered with learning how code works on a low level!
sorry.
Its just so good to here someone post about good programming habits instaed of what language makes it easier to code without regard to what there doing.
the question is: are you in the business to write code, or to write programs?
The Kruger Dunning explains most post on
Actually, strictly speaking the STL isn't even part of the C++ standard library. The STL (as designed by Alex Stepanov) is an entity in its own right, and the C++ standard library borrows very heavily from its ideas and maps them onto C++. The result of that mapping is commonly known as the STL among the C++ community, but the use of the term is not strictly accurate. There, that should settle the pedantry. ;-)
To answer your question more completely, the ISO C++ standard defines the following sections relating to the library.
Additionally, of course, there is what is inherited from C.
That covers the STL-based stuff (containers, iterators, algorithms), string manipulation, i18n issues, iostreams and such, the numeric classes (complex numbers, etc.), and various basic tools to make programming C++ easier.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You might try the Association of C and C++ Users web site.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
malloc() is not *part* of C, merely a POSIX system call. Granted, it's about the most essential of system calls, but if your book is about C, and C alone, you can leave malloc() out. I guess.
dinner: it's what's for beer
Interesting. However, many experts do disagree with you, including Bjarne Stroustrup and Marshall Cline.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Goodness, this is an awfully empty review. Except for the comment about the author's native language (which humorously is followed up by an awkward if not ungrammatical sentence from the reviewer), this whole review could be applied to practically any programming book! What sets this book apart? If nothing, then why review it?
Anyway, the real reason I clicked on this article is because I just love a C debate. Since there's hardly anything to talk about with regard to the review, let's get to it!
Here's what I say: outside of the low-level systems crowd, C should die. We should *not* be teaching beginning programmers C or C++. C should not be the "default language" of computer programming.
Today, efficiency is no longer the primary concern about software. It has been ousted by robustness and ease/cost of development (modularity and reuse). C is awful for robustness (the language lets you "get away" with anything you want, though those things are seldom what you want in application software), and even worse for modularity and re-use. Modern languages, or even quasi-modern languages like Java, are far better than C for robustness and ease of development. They even win on some points which are typically seen as less important than efficiency: portability, elegance, etc.
Finally, the efficiency of high-level languages is comparable (though not as good as) C. Compiler technology is improving somewhat, as well. But since developing and debugging take less time, you have more time to optimize your program (if necessary), so I am not convinced that this is really a big deal. Yet, even if I need to concede the efficiency issue, I still believe modern languages beat C overall.
I'll be glad to argue about that stuff, but today I have a different point to make. C is also holding back the progress of other computer fields. Let me give you an example. My friend is working on compilers that compile high-level languages (to them, C is a high-level language) down to circuits. Here, discovering data parallelism in the code is probably the most difficult problem. Of course, the same issues arise in compiling to architectures like the IA-64 or even P4, where in order to get best execution speed, the compiler needs to figure out what instructions can be executed in parallel.
When they compile C, they need to look for common idioms (certain patterns of for-loop use), then analyze them to extract the parallel algorithm. For instance, this simple C loop adds k to every integer in an array a of size s:
for (int i = 0; i < s; i++) {
a[i] += k;
}
The idea is that the compiler should be able to produce a circuit that does all of the adding in parallel, on silicon. Since you all probably grew up on C, this seems like the totally natural way to write that code. In fact, it is short and it is straightforward. Unfortunately, it is less straightforward to a compiler. The compiler needs to prove to itself that the for loop can be parallelized -- what if the programmer changed k or a or i in the loop body? The C code actually says to run each loop iteration sequentially.
Of course, compiler writers have gotten pretty good at catching this particular idiom, but when the code gets more complicated (especially when the compiler needs to do alias analysis), it is not so good.
The chief problem here is that the programmer is unable to effectively communicate his parallel algorithm to the compiler. The programmer takes something in his mind "add k to all elements in the list", sequentializes it for C "for (int i = 0 ...", and then the compiler has to *undo* this sequentialization to produce the parallel code. In the process of translating, some information is always lost.
Now look how this code would be written in SML (a so-called "modern language"):
Array.modify (fn x => x + k) a
(fn x => x + k) is a function expression (SML lets you pass around functions), and Array.modify simply applies the function to every element in the array. Here, the compiler can very easily tell that my operation is parallel, because I used Array.modify! The code is also a bit shorter, and I also think that this code is a lot clearer. That's subjective, of course. BUT, I hope you will agree that for this example, the SML code is closer to what the programmer means, and easier for the compiler to understand.
Anyway, perhaps some of you will say that this particular issue is not a problem, or that it is already solved (I would like to hear the solution!). I merely mean to propose an example of a theme I have been observing over the past few years in many areas of computer science. Computer programming is about communicationg with the compiler or machine in such a way that it is easy for the human to create code, and easy for the machine to understand it. C was never particularly easy for a human to create (though we have become accustomed to it), and though it was once easy for a compiler to understand, this is becomming less and less true. When the language is neither optimal for humans nor optimal for compilers, doesn't that mean that something needs as change?
It's easy to jump to that conclusion if you've been reading lots of C++ books, and certainly the IOStreams library has advantages over C's approach. However, it is itself fundamentally flawed for many applications, simply because it makes it nigh-on impossible to write code that's well-behaved in multiple (human-spoken) languages.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
We're not talking about "hello world". Try coding up 50k lines of C and see how well your memory management skills stack up.
> It's also _MUCH_ easier to write code without
> side effects, which is a bane to programming.
Hmm. I agree with what you say about C++ -- I think the language is awful -- and I agree that side effects are a bane to programming, but I definitely don't agree that C is good for side-effectless (ie, functional) programming.
For instance, implementing something as simple as binary trees without side-effects almost *requires* a garbage collector in order to get reasonable performance. (Maybe you could do something tricky with lazy reference counting, I dunno.)
In fact, since memory allocation is a side effect, even string manipulation in C is hard to pull off without side-effects. (How do you return a variable-sized string from a function?) On the contrary, C++ has value-semantics strings that make this possible.
And since C lacks first class functions (really, I should say it lacks nested functions, since you can actually pass around pointers), lots of the functional idioms just don't work.
What did you mean by this?
Sheesh. Certainly Prof. Greenlee is not the only exponent of this idea, but still, I find myself wondering in how many of his students he confirmed the fraudulent idea that you do your best work in marathon sessions, on your fifth cup of coffee, after three hours' sleep.
hyacinthus.
Does he have a Ph.D. yet ?
He's still just an instructor (AFAIK). I just refer to him as a prof because it's easier than explaining the real title. I also enjoy his teaching style but I'm glad he's the only one. I don't think I could deal with a full load of Greenlee-like profs.
Are you kidding, you want a copy of BOTH edditions. I still go back to my first edition K&R book when I need to know.
Maybe you don't have to make your code run on an old VAX as well as a system with a ANSI-C compiler, but I do from time to time. Even when I don't have to, I like to know my programs will work. (of course there are a lot of ansi-C tricks that I have to not use to make it work, and then put back in for modern systems, but I can deal with that)
Yeah, consistent, until your app decides to garbage collect. On most platforms, your app stands still, or usually at least gets sluggish. Hopefully, that is a good time, but the bad news is, you have no control.
To be fair, this is becoming less and less of an issue, but still an issue for hyper important/time sensitive apps. With C-style mm, you can decide when to free memory if you want.
room101 -- how much can you stand before they break you?
(they always break you eventually)
Show me a 30 year-old C compiler that's still in use.
The language may be mature; the knowledge that the compiler writers possess about the language and how to compile it may be mature; but I seriously doubt the maturity of most compiler code in use today.
By your rationale, we should prefer Fortran and Lisp
OOPS! I do (at least for most things). Never mind...
That is all.
There are real-time garbage collectors, which are guaranteed to not take longer than a fixed time.
Most modern garbage-collected languages can use generational garbage-collection, which, although not hard real-time, generally avoids long pauses, and is very efficient when much garbage is being generated quickly.
Malloc and free are generally not hard real-time.
Try reading the Garbage Collection FAQ
So when your customer runs your program for many months and happens to trigger some rare condition that you didn't test, he'll just leak memory, right?
This assumes that your test cases are always exhaustive enough to cover any possible order of reference creation and destruction processes, and have run times long enough to do so.
I'm not blaming my tools, I'm blaming your tools. When I program in Common Lisp, I don't spend a millisecond of my time debugging/preventing memory leaks. You seem to spend days. Which seems like a better use of programmer time?
Hasn't gcc been ported to the VAX? Seemed like it would have to have been, or the NetBSD Port would be impossible.
"(Man) tries to live his own life as if he were telling a story. But you have to choose: live or tell." --Sartre
One can use C++ for the Palm, but unless one knows the language rather intimately, it's easy to produce a big chunk o' code. That's because, depending what you do, C++ can link big libraries without your acquiescence.
The Palm requires the Old Virtues, grasshopper. Use simple C. Avoid non-Palm library calls.
You could do a lot worse than just taking some of the sample Palm code and studying it. The O'Reilly Palm Programming book is pretty good.
First of all, let me say that I see where you're coming from, and I agree entirely. I think it is important for people to understand the effects of the code they write, to an appropriate level.
However, I don't think your examples and conclusions follow from that as well as they might. For example, the inlining issue you mentioned (passing by value in C++) is a quality-of-implementation issue for your C++ compiler. It isn't a flaw in the langauge. It's a shame that we have to have idioms like pass-by-const-reference in a language at all today, since they are effectively nothing but preemptive optimisation and syntactic cod liver oil.
My other suggestion is that, while I do think it's advantageous to know what's going on under the hood, that doesn't have to come before learning a higher level language. On the contrary, those who have programmed C or assembler for years and who then try to pick up a language such as ML seem to be hampered by an intuitive need to understand everything that's going on under the hood, and to map all constructs and ideas in the language onto familiar low-level terms. This is counter-productive. We know that some higher level languages can generate very good code, with speeds and executable sizes comparable even to languages such as C or C++ today. Focussing on the little details -- trying to break down a complex construction in a high level language into low-level concepts -- hides the big picture, and we all know that your performance really depends on the overall job, not the little tweaks.
As a supporting fact, consider that today, most C or C++ compilers on Intel boxes generate better (smaller, faster) assembly language output than "hand-optimised" assembly written by the programmer. Issues like pipelining and parallel processing have rendered truly low-level programming a specialist art, requiring great skill. Since the people writing compilers specialise in that skill, I'm happy to let them do their job, and get on with mine using the tools they give me.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
_C Programming: A Modern Approach_, by K. N. King.
http://knking.com/books/c/
What I can say is, everyone I know who's on the C standards committee and has read this book liked it, as do a number of the regulars of comp.lang.c. I read an early printing, found maybe two small errors, and one basically correct thing that isn't the way I'd have done it. I believe he said the errors would be corrected in future printings.
Nice book.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
There is currently no 100% standard-compliant C++ compiler available, AFAIK. Comeau's is close, but even that has been suffering with getting export to work properly, and Comeau C++ seems to be several months ahead of the field in standards compliance.
You're right that most of the problems are with template support, but to the serious C++ programmer, those are serious problems.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
A few years ago I read a book that a huge "C" on the front. It wasn't about the language but about conspiracies and espionage. It had covered such things like a cannon ball price war in Portugal started by the British which resulted in the Spanish Armada being equiped with lower quality armourments. I think it was a better written book than the one covered by this review.
I don't know about decent games (Abuse had a Lisp engine), but systems to develop games certainly have been written in Lisp.
I would suspect that the best breakpoint for run-time efficiency is to have a C or assembly language rendering engine, with Lisp-based game action code. I.e. the dynamic portion that has to be easily changed is in Lisp, the part that has to smash data into registers as fast as possible would be in C or assembly. Of course, commercial Lisps typically have provisions for a Lisp-syntax expression of assembly code, so you can write assembler using Lisp macros...
cheers,
mike
public class Hello {
public static void main(String[] args) {
System.out.println("Hello !");
}
}
compare:
#include "stdio.h"
int main() {
printf("Hello !");
}
5 lines each. Its a draw.
Yeah, but we hadn't updated the vax in years. It was only used for testing in a lab, as a network traffic generator. Not internet connected so security wasn't an issue. Never saw a real load, so there was no point in upgrading to something more modern. We have plenty of more modern equipment to play with, so nobody wanted to upgrade the vax, though when you need a few more traffic generators they were there.