Live data from Hacker News

To become a good C programmer (2011)

fabiensanglard.net

31–40 of 135 posts

Re: To become a good C programmer (2011)

#31

One of the things I tend to think about these days is return on investment. I spent several years at the beginning of my career being a bad and then mediocre C programmer, and once I found a few other languages, I got the sense that being a mediocre-to-good programmer in these languages would be much easier, and that seems to have been borne out. Late into a career investing in other areas, what's the advantage of be…

Rust isn't viable for embedded platforms, at least not yet. It's not as easy to compile it to the most obscure ISAs as C, and the little support it has for stuff like STM32 is restricted to just that group of microcontrollers and doesn't support the entire ARM range. Maybe in the future? I'm looking forward to that day!

Go is probably never going to run on microcontrollers due to its very big overhead.

C perfectly matches on top of the hardware of a processor. Every single design decision about C was made with the computer in mind. Memory, pointers, stack, call stack, returns, arguments, just everything is so excellently designed.

Even Linus Torvalds says so! https://www.youtube.com/watch?v=CYvJPra7Ebk

If I were to make one change to C, it would be to completely rip out the #include system and bring a proper modules system. Apart from that, it's pretty much perfect.

Re: To become a good C programmer (2011)

#32
post #30
post #18

Earlier quoted context omitted.

Personally (3 decades+ journeyman C), I find lot of the advances are often about trying to get people out of bad practices (e.g. stdint.h in C99 to fix portability issues between 32 and 64 bit).

The names in stdint.h are ok, but the way they play with library functions like printf() and scanf() is not so great. Given an int64_t value x, each of these works on some platforms and is wrong on another: printf("here's your int64_t: %ld\n", x); printf("here's your int64_t: %lld\n", x); And the portable way using inttypes.h is really ugly: printf("portably int64_t: %" PRId64 "\n", x); There's another religious argu…

Then there’s the perennial problem of missing format specifiers for POSIX types like pid_t. Although you could argue that POSIX should mandate macros to appropriately handle them, the root problem is the same.

The default integer types have not aged well...

Re: To become a good C programmer (2011)

#33

This is a great list of books - at least, I found the same ones were the most excellent. Also I really learnt a lot from 21st Century C (The author here said they wanted to stick to C89, which is fair enough.) >To read great C code will help tremendously. But then he just gives examples of games I don't know and am not really interested in. Anyone know some non-game C that is, I suppose, well-known and wonderfully-wr…

The core Linux kernel is well-known and mostly well-written C.

Re: To become a good C programmer (2011)

#34

I feel like I wrote that a decade ago. Wait. Damn. It WAS a decade ago. Amazingly the list is still relevant. I will try to check out the new suggestions on this thread.

Have you read "C Programming: A modern approach" (2nd ed)? And if so, what do you think about it?

Re: To become a good C programmer (2011)

#36
post #26

> No website is as good as a good book Good (and often forgotten) advice for more than just C...

I don't agree with this sentiment. People learn different ways. I personally learn through trial and error, and explanations of things that I haven't been able to "touch" yet don't help me at all.

I like the K&R book, but I think what really taught me the most about C was actually writing programs in C. And playing around with particularly interesting features like function pointers and OS library interaction such as dynamic memory allocation.

Re: To become a good C programmer (2011)

#37
post #33

This is a great list of books - at least, I found the same ones were the most excellent. Also I really learnt a lot from 21st Century C (The author here said they wanted to stick to C89, which is fair enough.) >To read great C code will help tremendously. But then he just gives examples of games I don't know and am not really interested in. Anyone know some non-game C that is, I suppose, well-known and wonderfully-wr…

The core Linux kernel is well-known and mostly well-written C.

I'd say "advanced" C, not necessarily "well-written" C. There's certainly a lot of C in it, and I'd bet it's the largest open source C codebase.

Re: To become a good C programmer (2011)

#38

This is a great list of books - at least, I found the same ones were the most excellent. Also I really learnt a lot from 21st Century C (The author here said they wanted to stick to C89, which is fair enough.) >To read great C code will help tremendously. But then he just gives examples of games I don't know and am not really interested in. Anyone know some non-game C that is, I suppose, well-known and wonderfully-wr…

The sqlite codebase is well-known for being a large, well-written C codebase: https://github.com/sqlite/sqlite The tests in particular are very impressive. Some other notable C codebases: Redis, LuaJIT, FreeBSD, Memcached --> https://github.com/antirez/redis https://github.com/LuaDist/luajit https://github.com/freebsd/freebsd https://github.com/memcached/memcached

Varnish and the Linux kernel should be in that list as well I think.

Re: To become a good C programmer (2011)

#39
post #33

Earlier quoted context omitted.

The core Linux kernel is well-known and mostly well-written C.

I'd say "advanced" C, not necessarily "well-written" C. There's certainly a lot of C in it, and I'd bet it's the largest open source C codebase.

They go beyond C, it's actually C + GCC extensions. The only reason clang can compile it (in some configurations) is that they painstakingly implemented each of the GCC extensions the kernel uses (and when they were almost done, the kernel started requiring a few more).

Re: To become a good C programmer (2011)

#40

Why does everyone always suggest K&R? I really don't see the big deal. It's short, contains only trivial toy examples with no real world application, and touches almost nothing on actual project architecture or best practices. I bought it expecting to learn to write programs in C but it's really just a reference manual on syntax.

> Why does everyone always suggest K&R?

Because it's the best no bullshit book to learn C, period. Especially coming from garbage collected languages. It's not going to teach you valgrind or GDB, or even compile and link C programs but it will certainly teach you how to write C programs.

> only trivial toy examples with no real world application

Re-implementing POSIX commands is writing real world applications.

> and touches almost nothing on actual project architecture or best practices.

On what platform? Linux? Windows? Mac? tool chains are so different on all these platforms that it wouldn't make sense to spend time on that. That books is about C, not learning autotools and other horrors.

Post reply on HN