On becoming an expert C programmer
isthe.com
On becoming an expert C programmer
1–10 of 80 posts
Re: On becoming an expert C programmer
#2Not mentionned, about being an expert C programmer, is knowing the pitfalls of C, (cf. undefined behaviors), and reading and knowing the ANSI C standard.
Of course, just knowing the language in and out is not enough, you also have to be a good programmer in general (algorithms, "design patterns", software architecture, software engineering, etc).
But writing C code without undefined behavior, and avoiding its numerous pitfalls is absolutely necessary.
Re: On becoming an expert C programmer
#3This answer (http://programmers.stackexchange.com/a/229245/7146) is about managing code complexity but the lesson applies equally as well to becoming a better programmer with any language.
Re: On becoming an expert C programmer
#4Not mentionned, about being an expert C programmer, is knowing the pitfalls of C, (cf. undefined behaviors), and reading and knowing the ANSI C standard. Of course, just knowing the language in and out is not enough, you also have to be a good programmer in general (algorithms, "design patterns", software architecture, software engineering, etc). But writing C code without undefined behavior, and avoiding its numerou…
If you want to become an expert C programmer, you have to know C As She Is Spoke: Compiler quirks, inclusive of bugs and non-standard enhancements, which can either trip you up or give you a lot more expressiveness, if you're tasteful about where and when you use them. For example, the GNU C typeof() operator makes certain macros a lot cleaner, but it's nowhere in the actual standard. I'm sure other compilers have similar extensions.
Re: On becoming an expert C programmer
#5Not mentionned, about being an expert C programmer, is knowing the pitfalls of C, (cf. undefined behaviors), and reading and knowing the ANSI C standard. Of course, just knowing the language in and out is not enough, you also have to be a good programmer in general (algorithms, "design patterns", software architecture, software engineering, etc). But writing C code without undefined behavior, and avoiding its numerou…
operating system principles and quirks also equally important when you want a expert C programmer.
Re: On becoming an expert C programmer
#6Not mentionned, about being an expert C programmer, is knowing the pitfalls of C, (cf. undefined behaviors), and reading and knowing the ANSI C standard. Of course, just knowing the language in and out is not enough, you also have to be a good programmer in general (algorithms, "design patterns", software architecture, software engineering, etc). But writing C code without undefined behavior, and avoiding its numerou…
> But writing C code without undefined behavior, and avoiding its numerous pitfalls is absolutely necessary.
I rarely (as in unicorns) see C code that consistently checks for unsigned integer overflow. Or signed integer overflow for that matter, but that's defined behavior.
Point being, I also encourage people to avoid undefined behavior, but whether and how one does that has subtleties in practice.
Re: On becoming an expert C programmer
#7Not mentionned, about being an expert C programmer, is knowing the pitfalls of C, (cf. undefined behaviors), and reading and knowing the ANSI C standard. Of course, just knowing the language in and out is not enough, you also have to be a good programmer in general (algorithms, "design patterns", software architecture, software engineering, etc). But writing C code without undefined behavior, and avoiding its numerou…
> But writing C code without undefined behavior, and avoiding its numerous pitfalls is absolutely necessary. I rarely (as in unicorns) see C code that consistently checks for unsigned integer overflow. Or signed integer overflow for that matter, but that's defined behavior. Point being, I also encourage people to avoid undefined behavior, but whether and how one does that has subtleties in practice.
Unsigned overflow is defined, signed overflow isn't.
Re: On becoming an expert C programmer
#8Not mentionned, about being an expert C programmer, is knowing the pitfalls of C, (cf. undefined behaviors), and reading and knowing the ANSI C standard. Of course, just knowing the language in and out is not enough, you also have to be a good programmer in general (algorithms, "design patterns", software architecture, software engineering, etc). But writing C code without undefined behavior, and avoiding its numerou…
> But writing C code without undefined behavior, and avoiding its numerous pitfalls is absolutely necessary. I rarely (as in unicorns) see C code that consistently checks for unsigned integer overflow. Or signed integer overflow for that matter, but that's defined behavior. Point being, I also encourage people to avoid undefined behavior, but whether and how one does that has subtleties in practice.
Signed overflow is undefined, unsigned overflow is defined. But I agree with you. Not enough people take integer overflow seriously.
Unsigned underflow, perfectly well defined behaviour, is actually a worse problem in practice, IMO. I think too many C programers think about unsigned types like they're a bounded type, e.g. they think "this variable can never be negative, therefore I'll give it an unsigned type". But unsigned types have a cliff of surprising behaviour right where they're commonly used - most integer values in programs are low. Whereas you really need to work on a signed value to get it to overflow.
Re: On becoming an expert C programmer
#9Whenever I've looked at an open source C programs, they go well beyond what I've learned in K&R.
Learning C these days means mastering Make, autotools, macros, POSIX and Glib.
Knowing these is the difference between your contrived linked-list example and creating software that can actually be deployed and is useful.
Re: On becoming an expert C programmer
#10Whenever I've looked at an open source C programs, they go well beyond what I've learned in K&R. Learning C these days means mastering Make, autotools, macros, POSIX and Glib. Knowing these is the difference between your contrived linked-list example and creating software that can actually be deployed and is useful.
You make an excellent point. Perhaps more so than with other languages, getting to grips with making C actually useful relies a lot on quite extensive knowledge of the build environment.