Live data from Hacker News

To become a good C programmer (2011)

fabiensanglard.net

41–50 of 135 posts

Re: To become a good C programmer (2011)

#41

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

PostgreSQL’s source code is also really good. https://git.postgresql.org/gitweb/?p=postgresql.git;a=tree

Re: To become a good C programmer (2011)

#42
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…

What I wonder is, why didn't they add new *printf functions? So you could say 'printf("int64: %d64", x)'

Re: To become a good C programmer (2011)

#43

Earlier quoted context omitted.

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.

Nice! Here are the links:

Varnish --> https://github.com/varnishcache/varnish-cache

Linux Kernel --> https://github.com/torvalds/linux

Re: To become a good C programmer (2011)

#44

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 ma…

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

My employer runs go on micro controllers. Definitely suboptimal, but as long as the cost of increasing hardware capacity to accommodate Go is feasible then it's a viable option.

Re: To become a good C programmer (2011)

#45
The K&R book was for decades my gold standard of a programming book. Perfectly clear and concise, its one notable failing being that it's obsolete.

The Rust Programming Language [1] has since equalled and surpassed it in my mind. Hats off for Steve Klabnik & Carol Nichols :)

(note, I'm not saying Rust is a better answer than Fabien's recommendation, just that its book is as high quality as the excellent K&R)

[1] https://doc.rust-lang.org/book/

Re: To become a good C programmer (2011)

#46

Interesting comment they made about using C89 for portability. What's the state of C99 today? I know gcc doesn't support all C99 features, but what about other compilers? Is it worthwhile to use C99 in a new project?

You can safely use C11 or even C18 if you’re not too worried about support beyond Linux, macOS, and Windows with Clang. Game consoles and embedded development might require crappy old compilers that don’t support anything but C89, but otherwise use the latest version you can.

Re: To become a good C programmer (2011)

#47
post #17

In the 90s, most seriouc C programmers knew about these books. They were the core books most devs relied on and referred to. They're all good. I disagree with this comment: "No website is as good as a good book. And no good book is as good as a disassembly output." There are many websites today that are excellent. And there are many websites that cover obscure topics not found in books. Finally, I think it's importan…

> But today, there is little reason for most projects not use the advances found in C99. Does visual studio support c99 yet? Last I heard MS wasn’t interested in supporting it.

It supports most of it. Useless stuff like VLA is still uninmplemented though.

Re: To become a good C programmer (2011)

#48

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…

For me it is a smaller dependancy stack. For example I needed some tooling that worked on RHEL/CentOS, back to version 4.x and 3.x (yes, I know). Also, someone at work wanted me to get into Swift... They had Ubuntu packages but nothing for RHEL or Fedora (that may have changed now though).

Re: To become a good C programmer (2011)

#49

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…

C is still king in embedded systems. It is also great at making you aware of the machine. In C, very little is happening behind the scene. If you want something to happen, you need write some code. Objects will not initialize themselves, allocated memory will not free itself, no smart reference mechanisms, just explicit pointers. This understanding of the machine will help understanding why higher level langages behave the way they do.

But anyways, programming skills is not so much about the language. A good programmer in one language will be a good programmer in any other language very quickly. But still, if I have to hire a programmer for a project in a language he doesn't know, I will tend to prefer C programmers over those who only use higher level languages. The reason is that C programmers may do things that are not pretty, but they usually understand what they are doing, people who are only accustomed to some higher level language may come up with better designs, but write code that make no sense.

Re: To become a good C programmer (2011)

#50

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 ma…

TinyGo recently became an official project and seems extremely successful.
Post reply on HN