h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

In my view, the best book for learning C remains Kernighan and Ritchie. I tried to apply the same argument to C++, but Stroustrup's is almost unreadable.

Although gcc did originally stand for GNU C Compiler, it was really named because most of the GNU versions of basic UNIX commands are just "g" perpended to the UNIX command name (in this case cc). When they're not, of course, they're usually the result of some really bad pun.

I think one of the reasons why C gained popularity and remains popular today is that it combines ready access to the lowest level of the machine (through pointers and low-level i/o libraries) when you need it, but at the same time is ideally suited to abstracting the concepts to allow programmers to concentrate on the real task in hand.

C rules. Period.

But, IMHO, the best book for C is "C For Dummies", by Dan Gookin.

Another book worth looking at is 'Safer C' by Les Hatton, particularly if you're forced to use C for safety critical applications (not a good idea - it's too easy to write bad C code). This isn't a 'Teach Yourself C' book, it's a book that points out the things that can go wrong when writing C (in great detail!), and why these things can cause problems later.

As an example, good old 'signed to unsigned conversion' - we've all done it. The lift (elevator) in the Sheffield University Arts Tower, UK, is software controlled. The position of the lift in the tower was stored in centimetres as a signed integer, giving it a range of 32767cm to -32768cm. However, when the lift was called, the position was checked as an unsigned integer (0cm to 65535cm). Over time the mechanism wore and the lift dropped by 1cm, giving a lift position of -1cm. When the lift was called, the function that checked the lift position decided that the lift was 65535cm above ground level (appreciably higher than the top of the tower!) and tried to bring the lift to ground level. The lift was rammed hard against the buffers at the bottom of the shaft and refused to move upwards.

As a software engineer of many years experience, I feel that C is all very well in its place, but there are better languages for some applications.

Kernighan and Ritchie was probably the best £25 I ever invested. I've lived off it one way or another for 15 years.

The only other comment I'd make here is that C has the most examined syntax of any programming language. (I think...)

Some years (10?) ago an argument erupted in Computer weekly surrounding what you get when you try to use &p as in.

int *p;

[what]=&p;

This ran for several weeks in a letters page and was finally laid to rest by Mr Ritchie or Mr Kernighan (I cant remember which now). With the helpful statement that it is undefined... but could be compiler dependent. This was before ANSI standard C.

"C for Dummies" is a truly disgsting book, sorry. A good many of the programs will not run on any modern compiler or on any modern OS. It's more like a book to read to see what sort of bad habits you can pick up by learning to program on a toy OS. Only Herbert Schildt's books are worse.

To learn C, pick K N King's "C Programming: A Modern Approach" or Deitel and Deitel's "C: How To Program". Or, of course, K+R.

I've not used Schildt's books to learn C - I did that 'the hard way', by using it! However, I found one of his books on C++ very useful. At work we had 'C++ for Dummies' which, IMHO, is a hunk of junk. When learning a language I like lots of exercises and examples so that I can check that I'm really getting to grips with the language. Schildt's 'Teach Yourself C++' isn't great - there are some areas which it doesn't go into in great depth. But it does teach you the basics very well, and it does have plenty of exercises, which is something the 'Dummies' book just didn't have.

My experience of K & R's C book is that it's great as a reference, but not to learn from (no solutions to those exercises, so you can't find out where you're going wrong if they don't work). Similarly with C++ (maybe this should be a new article). Stroustrup's book is the 'Bible' of C++, but I don't thing you could learn C++ from it.

Anyone here ever try Objective C? I believe that it was a much better attempt to graft OO onto C than C++. It had a much more concise syntax and that same simplicity that makes C so easy to learn.

I went for the cheap option - literature is v.v.v. cheap in India, so I went out there and got a book called 'Exploring C' by Yashavant Kanetkar. Never looked back - IMNSHO there's more in those 13 chapters than all of 'C for Dummies'.

Al (et al)

I did sort of learn my C++ with Soustrop - although I know a bit and I had programmed in C for about 6 years before that. Mind you I had broken my ankle and was on a hospital ward: out of the three general classes of people that are in hospitals (children, pregnant women, the elderly), I was in the geriatric ward. However he does get a bit wierd when it comes to the STL function objects and the other more esoteric recesses of the STL, and it didn't help that when I got back to work that M$'s VC++ didn't implement the functional header properly. At least I don't think it did : I was simply unable to get the thing working but unable/did not have time to wade through the myriad interconnected prepro symbols and had to provide the first_argument_type etc. definitions myself.

I would say that much STL is a definite departure from the imperative world and takes on a lot of declarative characteristics.

Later I learnt Java [not to mention JavaSpi^H^Hcript, Python, Perl, HTML, XML...]. Comparisons? C++ very definitely has Pandora's box like attributes. The STL serves to limit them, but you still have to pull a whole load of little tricks to program in an effective object oriented style, things that Java accomplishes very simply and clearly with 'abstract', 'interface' and 'final'. Exception handling is not enforced rigorously. And let's face it, garbage collection takes a whole burden off development. There are things I like about C++ that I wish were in Java: templates [apparently they are coming in *sometime*], operator overloading [sorry, I don't like being told you can't use it because it's possible to abuse it : if Java allows anonymous inner (lambda) classes to be instanciated 'on the fly' - a clear temptation for syntactic abuse by those so minded - it can damn well have operator overloading and be happy about it. All you have to avoid is overloading && and || because of the change in the semantics of short cut evalutation of boolean expressions, and Java could enforce this as it hasn't let it slip out like C++ did. Actually there are some prepros that produce operator overloading - by replacing them with compilable standard Java method calls, obviously], const [I *do* like being able to state clearly and enforcibly that some method is an accessor and not a mutator - naturally mutable would have to be defined as well to allow the implementation of lazy evaluating accessors] and maybe one or two others that I can't remember at 5am in the morning. That said, C++ has its place in allowing C code to be incorporated into an object framework for the sake of manageability and C certainly still has its place in the world. Yes it has its problems but "Don't Do That Then". I have worked with people who were baffled as to why insurance code would fail at adding one client when 32,767 where present in the system, etc. but it isn't anything that isn't soluble by a sharp pointy stick. But then I quite like the way Python and Perl are put together with C-implemented modules where performance is crucial, allowing for the flexibility of the scripting language around these tuned beasties. Well, when I say I like the way Perl is put together, what I mean is, er... um...