Becoming an Expert

So you've decided you want to become an expert in C. But what does it mean to be an expert? Anyone who has done a few projects in C (or any language) probably has this idea that they're somewhat of an expert, at least until he or she starts poking around on comp.lang.c for a bit.

If I were to start from the beginning, the first thing I would do is read a book on basics. Then I would work on some small projects and then some larger ones. Eventually I would want to measure my skill level by asking some of the following questions.

• Do I understand what pointers are?
• Do I understand multidimensional arrays?
• Do I understand the relationship between pointers and arrays.
• Do I understand pointer arithmetic?
• Can I declare and use complex types (pointers to arrays, arrays of pointers, arrays returning pointers to functions, etc.).
• Do I understand both static and dynamic memory allocation?
• Am I familiar with all the basic control structures?
• Do I understand how to use structures?
• Do I understand functions, stacks, and heaps?
• Do I know how to work with low level bit manipulation operations?
• How well do I know the precedence of operators?

If I found myself answering yes to these questions, I would say this is a good start. But how about the standard libraries? What good is knowing the language without some libraries? Am I familiar with all the standard headers and the functions, variables, and constants in each one. Do I know how to use the functions? Am I familiar with the design issues and quirks of the library?

It's good to know the libraries and the language. But am I familiar with the official standards, C89 and C99? Assuming I knew some compiler theory, could I implement a compiler that conforms to these standards? Can I write code that will work on any conforming compiler? Do I know what is C and what is a language extension by my particular compiler?

knowing the standards is good. But it sure would be nice if I understood how to write real world code. Writing some short projects isn't quite the same thing as working on a project that's tens of thousands of lines or even hundreds of thousands of lines of code. It's also a good idea to review other code to see how problems are commonly solved in C.

For maximum exposure, I would want to work on various types of projects. I would write some networking code, implement some data structures and numerical algorithms, work on some human interface code (GUI, command line), etc. Different types of problems tell you about the language's strengths and weaknesses.

But I really need something to compare to. This means I should also be familiar with at least two or three other languages as well. After all, how am I supposed to know about C's efficiency without comparing it to a language like Python. And how would I know that pointers and memory allocation and null characters are all things I could often do without if I hadn't tried a higher level language?

And still there's more. Don't you agree that I should learn something about the history of C? How did it evolve? Why can I not add character strings? Why can I add pointers? How were these decisions made? Why were the standards made the way they were. Understanding these questions helps me understand the language.

Perhaps I should learn something about my specific compiler. Understanding the various compiler options should help me understand the language better. Do I know how various compilers differ and why? Which features conform to standards and which ones don't? Do I understand how the compiler works with the linker? What responsibilities belong to the compiler and which to the linker?

Maybe you can think of more ways to improve your skill and understanding. Go and hang out at comp.lang.c. Read the FAQ. Experiment. Read code. Study solutions to difficult problems solved in C. Implement the same code in multiple langauges. Read through the libraries. Read the standard. If you do even half of these things, you'll probably know far more than me.