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.
usually use man if my collegues and I are any example.
I love a review that isn't afraid to say "don't bother"
Here is the Amazon review of the book.
At least it goes into more detail...come on slashdot!
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
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".
All in all, you'd give the book a grade about... "C"? :)
"Recta non toleranda futuaris nisi irrisus ridebis"
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!"
C was written in the dark ages of second generation languages, when the concept of a programming language was quite a new idea. It was all well and good in its time, but it has been suprceded by any number of other languages. Quite simply C lacks any of the benefits of any other language.
C has no bounded array support. This makes it inherently unsuitable for any security programming taks. The concepts of pointers, structures and unions is totally confused. The typeing can't decide whther its a stronly or losely typed language, so it is possible to cast a pointer to an int to a pointer to a float, and have a different result from casting an interger to a float.
And the support for OO techniques is minimal to non-existent. No templates, no classes. No inheritence. Unlike C++, self modifying code is impossible in a non-platform specific manner. Unlike Perl and Haskell, it is next to impossible to extend an array.
The #include mechanism is a joke. It requires that you type the name of a function at least 3 times, and then you have to deal with circular include paths, and multiple includes of the same file. Support for 32 bit architectures had to be added afterwards in the form of a long keyword.
There is no equivalent of the object class. Can you believe that people are still programming in a language that doesn't have this useful conmcept? Most of the functionality in C is available in MSDOS batch scripts!
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!
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.
I had about 20 technology-related books in my collection, but after time I was realizing that I never used any of them anymore, and I find online resources to be much more valuable as well as much more current than books can ever be. There really needs to be a large push to get away from printed copies of books and possibly XML-formatted online versions.
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.
That said, if you're looking for a less expensive book, I'm a big fan of the WROX series. The writers tend to have a good grasp of the english language (which many authors of programming books, sadly, don't), and use worthwhile examples. They're written for folks who don't know anything at all about programming, for the most part, and they're quite good. They also run about $35, or about half of what most of the "real" programming books cost.
*shrug* I also found that most of the really good (read, popular) ones didn't explain things in a way I understood, but that could just be me. For instance, I find O'Reilly's books to be excellent as reference manuals, but terrible teachers.
Oh yes. Java. How useful a language. And gee, you can do anything in it. Perhaps I'll write the VM in Java... oh, wait.
Maybe I'll write an efficient embedded OS in Java... oh, wait.
OK, I'll write my device drivers in Java... oh, wait.
Alrighty, then. I'll write my large, distributed database system in Java. Hey, that'll work! Too bad Visual Basic would cut my development time in half.
Java is a fine language for SOME things. Just don't think that any serious OS or embedded-systems engineer would even consider it.
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."
When people talk about "K&R" as a book, they're referring specifically to "The C Programming Language" by Kernighan and Ritchie (amazon), which is, without a doubt, the best reference available for C, and well worth the $40 its gonna cost ya.
Mind you, its probably not the best book to learn C, but once you have the basics, this book will become your bible. I keep a softbound copy at home, and a nice hardback version I found at a used bookstore at work. Absolutely indispensible.
--
Disclaimer: The above statement probably includes half-truths, because real truth is too complicated.
And OS kernel code
And device drivers
And games (speed)
And HUGE amounts of legacy unix , vax & mainframe
code
C aint dead yet
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.
It seems that Dennis Ritchie was so besotted with A and B...
Actually, the precursor to B was BCPL, not A. B is C's precursor.
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
C has no bounded array support. This makes it inherently unsuitable for any security programming taks.
*cough* *NIX is written in C *cough*
If the computing industry had any sense, it would have switched to Java 10 years ago. Why hadn't it? Inertia!
Let's just think of how fast x86 Java VM's were 10 years ago. In 1992 I had just purchased a Macintosh Quadra (25mhz), Windows NT wouldn't come out for a year later, and Windows 3.1 and OS/2 2.0 had just came out. The Sparc 10 had just been released. Pentiums were not coming out for a whole 'nother year.
The HotJava browser didn't come out until...1994?
A C book that doesn't cover a proper coding style is pretty useless.
Yeah, you might bang out a quick "itch-scratcher" without using a strict coding style, but not a solid piece of software that can be maintained.
The think that sux about rox books is the lifeless faces of the authors that stare back at you. There is a guy at work here who actually put a cover on the book so he doesn't have to see them. I'd rather see a yak or something than those jerks!
love is just extroverted narcissism
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.
Are not all other programming languages that are popular today, just extensions of the 'C' base? If you look back 'C' it is the first cross platform language, take JAVA which is really 'C' with an OOP style and a few syntax changes.
A quote from the reviewer: "C is difficult enough to present without a language barrier introducing more problems." I think he is confusing 'C' with 'C++'; which can be a very confusing implication of 'C'.
I think a first time 'C' user would be well advised to get one of the 'K&R' programming books. I found it very helpful when I was learning 'C'.
Wise men speak because they have something to say, Fools because they have to say something!!!!
[cough] STL is part of the standard library. They are not the same thing. [/cough]
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 don't know why they even write C books. There has always been and will only be one programming book "the C programming languaje" by Kernigan Ritchie. Not only a superb C book, simply put, the best programming book ever. Now I'm looking for a similar book on JAVA, but all the books I found are tooooooo big. So far, the best JAVA book I read is "Just JAVA and beyond" by Peter Van Der Linden. Chapter 2 is all you need to know about OOP.
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.
*cough* *NIX is written in C *cough*
Good. Now choose an OS with no known buffer overflow exploits.
Quite a supplement to K&R.
I don't necessarily disagree that the memory
management complications in C cause problems,
but, I believe that OpenBSD has no known
buffer overflow exploits, at least in the core
OS.
"A man talking sense to himself is no madder than a man talking nonsense not to himself."
Though its been a while since I have programmed in C, I think it is worth noting, for new users, that learning C, is a lot easier than trying to learn C++. I tried to learn C++, but as a newbie programmer, it got very confusing. I don't remember why, but C was just a lot easier to learn. I never went on to study C++ (perl got really interesting). But, my advice for anybody wanting to go into programming, take a look at C first.
Andrew Koenig
Still the best after thirteen years.
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.
A good C reference would be one thing, however, this sounds like more of an introductory general C comprehension book, and in the vein of those that have gone before. What use do coders have for this? If we know C we need a more specialized discussion, and if we don't, there are canonical texts to refer to (K&R).
OTOH, it warms my heart to see interest in C. it's really my favorite language, and while i don't mind that most employers want me to write OO code, i would hate for C to fade from the earth (especially in favor of C#).
For a person who doesn't program in C and never learnt C++ (because Perl, of all things, distracted him) I would suggest that your comment is worth about nothing.
How we know is more important than what we know.
Having learned VB and Java first, and having read many books on computer architecture, I would suggest that the only book you need to learn C is K&R. The Wrox books have too much fluff for someone who just wants to get down to what's important.
In addition to K&R, The C Standard Library by Plauger is also quite useful. If you're not the type of programmer that can pick up language basics in a few days with a good reference, then, by all means, get something with less substance and more hand-holding. I also managed to find a book on nothing but pointers in C, but, unfortunately, do not have it close by to pass on the title. It's somewhat old, and may be out of print, anyway.
Real software engineers regret the existence of COBOL, FORTRAN and BASIC.
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++).
always the need to:
1. Be a smartass.
2. Show off your expertise, while
3. Not helping anyone.
always the need to:
1. Be a smartass.
2. Show off your expertise (self-perceived), while
3. Not helping anyone.
Isn't that an awfully low standard? Kind of like saying a rule of thumb for picking a book on baking bread is to put it back if it doesn't mention flour. Well of course; but that leaves room for plenty of bad books to make the cut. A C book would have to be trully awful not to mention malloc. In fact, I have a hard time believing such a book exists. A more accurate rule would be "If the book doesn't mention malloc, put it back - you picked up a C++ book by mistake, idiot".
--
CPAN rules. - Guido van Rossum
If you're "man enough" to write a program with no memory leaks, you've probably also written a program that can't function as part of a long-lived dynamic system.
That is, if your program is simple enough that memory allocation can be handled manually, then it probably isn't complicated enough to do anything interesting. Where by "interesting" I mean, can do things with data that are too complicated to get a human brain around without making a mistake---such as running queries against complicated databases for flexible, user-configurable front-end applications.
Why is it that most large projects start out with defining a memory-management subsystem? Why not use a language that has a robust memory management capability built in, and save your presumably valuable time?
A good programmer can manage memory without the help of the runtime environment
I agree, however, one must consider that we live in the real world. A world in which a very small percentage of programmers are "good programmer"s. That's why there is a need for, um, simpler languages. One for the "common" programmer. Sort of a VolksLanguage, or VPL.
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.
I guess it's the programmers and not the language that determine the security
DING DING DING DING DING. Give the man a monkey!
While we're on the subject of good books, one that should definitly be looked at if you are getting started with any kind of socket programming in C is The Pocket Guide to TCP/IP Sockets: C Version. It is short (~100 or so pages), to the point(lots of examples which actually work with linux and cygwin if you dare), and most importantly, CHEAP ($15)
Go check it out here
In case of fire, do not use elevator. Use water!
No kidding. The PHP book is the worst, though. Check out the guy on the left in the second row.
BWAHAHAHAHAHA!
Funny guy.
Harbison and Steele's "C: A Reference Manual" is the book I use. I like it a lot. This is "real-world" C, full of guidance on things which are in the standard but frequently implemented correctly (so you can avoid them if you want to be conservative), or things which are not in the standard but a frequently implemented in a certain "traditional" way.
It is valuable because it does NOT have the "one-vendor" myopia that is so common elsewhere.
IMHO, it is better organized and better written than K&R. And, unlike K&R, which describes C the way K&R would like it to be, Harbison and Steele describe C the way it is.
"How to Do Nothing," kids activities, back in print!
However, there seem to be many gaps in the C++ book market.
Of course this brings up an interesting point. One of the things I LOVE about C is that it's a straight forward language. Sure you can create some hairy messes, but once you understand some basic concepts, most of the language is accessable to you. It's also _MUCH_ easier to write code without side effects, which is a bane to programming. With little effort, one can look at some C code and have a reasonable idea about what's going on. With C++, a line of code is never what it seems, and you usually have to track down a dozen h or cpp files to figure out what the heck is going on. C++ is the best damn employment insurance ever created for programmers
With C, you can get away with a couple of good reference books. With C++, you can never have enough reference books.
Which is exactly his point.
Gee, and it took only 30 years to get to that point.
Is there a good C++ equivilent to _the_ K&R C book??
A good programmer wouldn't waste his time doing it himself. Reinventing the wheel is nothing to be proud of.
Don't forget to mention that C is missing important features of C++, like templates and many others I have no time to explain here.
STL is part of the standard library. They are not the same thing.
Other than STL, iostream, and the C library, what libraries does the C++ standard define?
Will I retire or break 10K?
Then where have all the good programmers gone? Or have they all moved over to Lisp?
I like OpenBSD, most secure OS hands down.
But there are still bugs in there, the guys keep fixing them...track the OpenBSD developer mailing list.
The alternative is that he is so lame as to not be worth discussing (which may also be true).
At one time, we were all that lame. Be nice.
Will I retire or break 10K?
Started off with K&R, and 5 years later picked up Expert C Programming, and Koenigs C book. I found all of them to be valuable, even though similar information was found in the last two books. A different perspective, and additional examples of folly are always welcome.
Allow me to make a little C question.
I have a function that receives an array and analises it.
Then it returns another array with some information in each "position", like
info[0] = width
info[1] = heigth
The function woule be called as:
result = analise (myarray);
A couple of cicles generate the "info" array, and then I need that thing returned.
AFAIK in C it isn't possible to return an array from a function, so, how do I do this thing?
Thanks.
6. It is a very elegeant and consistent language (unlike C++).
... and most ppl took C++ because they were told it would be so easy (if I recall correctly, I was the only one to prefer ANSI-C) :)
... it is one of the most well written books on C that I have found. And it's now out of print ... I thought about buying another copy (I sold mine back because I was a broke college student)
This is why I decided to use ANSI-C rather than C++ when I took my C classes in college. The professor gave us a choice
I was using AmigaOS and AIX at the time and knew that the only standard across platforms tended to be ANSI-C.
Incidentally, the book I used was The Joy of C
- 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.Be careful that the hardback copy you have is a Second Edition copy, and not the original, non-ANSI C, First Edition.
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'm sitting here reading all these posts and I can't help but realize that a lot of people are missing the point. Every language has its time and place. The average Joe trying to live the hacker ethic has little hope of using the more advanced languages correctly. It takes time, education and gasp ... skill to program. You may not have an A game to code but don't bash a language because you don't have the skill to accurately choose the correct language for a problem or understand the paradigm it was created from.
C++ is not the best language for all problems ... sometimes the solution to a problem dictates simplicity which C, or some other language, can provide.
The same thing can be said about books. Each has its time and place and attended audience ... don't bash if it wasn't meant for you.
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
If you like van der Linden as an author [in real life, he seems to be something of a cocktail party marxist], you should try his Expert C Programming: Deep C Secrets. It's a great read for the intermediate to advanced C programmer; I once used it as the basis for a course I taught in intermediate C.
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.
Agreed! Nearly all the other programming books are huge. To think, K&R introduced the whole language in just over 200 pages with clear examples and a lot of white space. It also makes a great reference book, maybe because it's so easy to find the important things.
to err is human, to forgive is divine, to forget is... umm...
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?
Addison Wesley, as most of us know, already has a vast array of great programming books. This is definitely not their entry in the field.
Since everyone else has done it, I thought I'd put in my recommendation for one of my all-time favorites: Expert C Programming, Deep C Secrets. This book is awesome and full of insight. Just look for tha orange book in the programming section of your favorite book store.
Ken Reek's Pointers on C is a very complete reference. I strongly recommend it if something more full than K&R is desired (as do many of the amazon.com reviewers).
We're not talking about "hello world". Try coding up 50k lines of C and see how well your memory management skills stack up.
When I was at GA Tech ('93-'98), Greenlee only had a Master's degree and was an "instructor" rather than a flavor of "Professor" such as "Assistant Professor", "Associate Professor", "Full Professor", or "Professor Emeritus". Does he have a Ph.D. yet ? I actually liked his sadistic teaching style, even though most people didn't. Though, nothing about Greenlee is suprising. He tends to have pretty extreme viewpoints.
Biodiesel : domestic, renewable, clean, and in the fuel tank of my bone stock 2002 New Beetle TDI
Also, IMHO c is one of the most elegant and powerful languages around. Written correctly, it is one of cleanest languages that exists.
On other languages:
- Java and C++ are disgusting to look at and overly complex.
- Python is a hack.
- Perl is ugly.
You have to really step up into the higher level prototype based languages like Lua before you get to a point where the code is elegant again. But before you program in any of these 'next generation' languages, you really have to understand what their built with.
my 2 cents.
-- "The best way to predict the future is to invent it."
> 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?
One of the first things I do when I start a new semester teaching C (yes, there are still classes out there in this fine language), I always bring my dog-eared K&R. Then I say "we're not using this book - it is a classic and I refer to is often, but it is too dense." Then I heft my copy of "C Programming" by KN King, soon to be published in its 2nd Edition, and say "this book may be all you'll ever need." I'll check out the new "C" book, but I suspect it won't outside King's.
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.
All of the latest versions of the C++ compilers I have used lately are either ANSI-C++ compliant or come damn close to being compliant : Diab (for embedded systems) GNU g++ Sun CC Visual C++ (gasp !) What most compilers got hung up on, in my experience, was templates. Now that STL has been out a while, it's forced any decent compiler to come up to spec..
Biodiesel : domestic, renewable, clean, and in the fuel tank of my bone stock 2002 New Beetle TDI
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)
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.
No Pascal.
is one that advertises a 12 step program for C programmers.
.... ;
char *step_array[] = {
"Get your C-compiler.",
"Walk to the trash can.",
"Deposit the compiler.",
"Set the trash can on fire.",
"Pick out another language.",
for (i=0; i12; i++) {
strcpy(cmd, step_array[i]);
system(cmd);
}
I have no sig.
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.
A garbage collector inflicts a significant run-time overhead to the system it's running on. Garbage collection is explicitly not in C++ because of this reason. However, there's nothing preventing you from linking in 3rd-party garbage collectors.
Biodiesel : domestic, renewable, clean, and in the fuel tank of my bone stock 2002 New Beetle TDI
Maybe I'll write an efficient embedded OS in Java... oh, wait.
Wait no longer. J2ME is here. Yes, I understand what you're saying (C tends to be more efficient than some other popular languages for writing stuff that directly bangs on the hardware), but an embedded Java OS does exist.
Alrighty, then. I'll write my large, distributed database system in Java. Hey, that'll work! Too bad Visual Basic would cut my development time in half.
Time is money, and money is time. The Java tools are available for almost free as in beer (Mandrake CD + Internet conn for downloading J2SDK). Visual Basic, on the other hand, costs much more per seat (Windows XP Pro license + Visual Studio license + Windows licenses for all the testers' machines), money that somebody has to earn. Does your estimate take into account the opportunity cost of the time you spend working to make up the cost of expensive software licenses?
Will I retire or break 10K?
"The C++ Programming Language" by Bjarne Stroustrup
Heap fragmentation, my ass. I guess you know nothing about "steady state" or "reaching equilibrium". Eventually all programs with bounded memory reach this state. I have server apps running for months that don't experience this supposed fragmentation you speak of - with completely deterministic (fast) memory allocation and deallocation. Why don't you actually LOOK at the source code of a good malloc library to see why it does not happen as you claim.
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?
1. I never said malloc/free were "hard real-time", I just said that the programmer could choose when it happens.
2. Because I said something like "this is becoming less of an issue", I had hoped that intellegent people would understand that this is a general comment and not an absolute statement. Yes there are special cases/workarounds/advances, but generally, you make the trade-offs that you feel comfortable with.
Do I think that garbage collection is probably better? You bet, but the point is that the programmer decides everything with the old way (for better or worse) and with gc, the system/library decides. Usually that is a good thing, but not always. (once again, this has been espacally true in the past, but yes, progress continues)
Yep, that gcfaq is interesting, I have looked at it before. The only thing I don't like about it is you get the feeling that they think that anyone who doesn't use gc is just obviously retarded.
room101 -- how much can you stand before they break you?
(they always break you eventually)
Have you seen the average progammers desk? Are you telling me you trust HIM to take out the trash?! He needs maid service (Java).
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
But of course! There's Stroustroup's "The C++ Programming Language" which is a thorough reference to the language itself, and how to use it effectively. As well, there is Josuttis' "The C++ Standard Library." Together, they make a great set.
== I am not Me.
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
"C Unleashed", by Heathfield, Kirby et al.
a sp ?theisbn=0672318962
http://www1.fatbrain.com/asp/bookinfo/bookinfo.
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.
How old is you VAX C compiler?
I remeber DEC releasing a version of their C compiler that tracked the ANSI C Specification (circa 1989). I had to make quit a few changes to some programs I wrote, since the K&R version of the VAX C compiler passed strutures as a pointer, while the ANSI C Standard changed the behavior to pass by value.
Personally, I write my own malloc routine (based on standard ideas of course) and ensure that all dynamic variables are released between various stages of the game (long-lived data is statically allocated). It works, since I don't tend to allocate piddly bits of memory.
Of course on PCs I just use the STL to take care of memory, because they have lots of it and its safer.
I have this book and I 'love' it. It's the only C book you need to get started and it will introduce :-) This is book is from the same publishing house as the one being reviewed.
you to some UNIX programming contructs too like fork . Well written, a little dense but you will find an answer to what you're looking for. The section on pointers is excellent. oh, realloc is only in the index
Peter
www.alphalinux.org
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/
I agree with "How to Design Programs" (MIT Press, available online with a great Scheme environment usable by beginners) as well as experts) that Scheme is a great first language.
The Teach Scheme Project and the "How to Design Programs" web sites have some very good arguments in favor of using Scheme as a first computer language.
Anyone who hasn't memorized K&R by now isn't worthy ;).
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.
Harbison and Steele's "C: A Reference Manual" is an extremely thorough and detailed reference manual. Not a book from which to learn to program, but an excellent book for experienced programmers (either just learning C, or wanting something deeper than Kernighan and Ritchie).
Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup.
Expert C Programming by Peter Van Der Linden
A recommended text for my second year programming course, it's a bit different to all the other C books I've read. Instead of just going over the syntax, and (intermitently) mentioning that X is a good way to do Y or foo should be baz'ed, it's a set of chapters on different aspects of C. There's on declarations, a chapter on how pointers and arrays are not the same, etc. Also nice is the humourous and informal style the author uses, peppered with jokes about PC architecture and Microsoft.
50,000 lines is the equivalent of a senior project for a CS bachelor's degree. If you are honestly suggesting that you can't write 50K lines of code without getting in trouble with your memory management, then I would suggest (no, I would plead) that you stick with Visual Basic or something else sufficiently easy. I'm the project lead for two systems written in C, both of which have over 1.5 million SLOC. Neither systems have any memory management skills. This is because we actually know how to code.
.. in the Microsoft era, developers shouldn't have to know how to code! It's just a nuisance that gets in the way! It is hateful and elitist to suggest that developers should have any sort of skills whatsoever! Bah. You know, I don't care if it is elitist. I can code circles around any of these drooling VB veggies that the two-year Vo Techs are cranking out, and I'm not afraid to say it. Oh yeah, and I've actually got a strong base of knowledge when it comes to mathematics and abstract CS theory. Ask any of these morons to explain a Turing machine to you, and they start bawling.
Oh yeah, that's right
Neither systems have any memory management skills.
:)
This was meant to read "Neither system has any memory management problems."
One of my professors, one of the old guard of the department, told an interesting story to my Formal Languages class a few weeks ago. He said that back in the 70s, Kernighan and a few of the other Bell Labs guys had been at our university for some conference or another. Our professor asked them about the design of C, and they told him this:
Some of the members of their group had expressed their concerns with the language - that it was a bit confusing, and that the many levels of precedence were a pain to deal with. They replied with, "Don't worry, it won't see any outside use."
Classic.
Verilog is a language with C-like syntax that compiles to hardware. How is your friend's work different?
In real time systems you don't allocate things
;-)
during time critical processes.
(everything being preallocated during program
initialisation).
You can't do that with Java (i.e. it should
be very very difficult, more difficult then writing in assembly
=> no real time with java.
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.
lol
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.