Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To become a good C programmer (2011)

fabiensanglard.net

Post reply on HN
Print view View original

21–30 of 135 posts

Re: To become a good C programmer (2011)

#21

Post by eindiran »

yesenadam wrote: post #2

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

Re: To become a good C programmer (2011)

#22

Post by fao_ »

ternaryoperator wrote: post #12

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…

> And there are many websites that cover obscure topics not found in books.

Yup. Are there any books covering the same content that ctyme does? (http://www.ctyme.com/intr/int.htm)

Re: To become a good C programmer (2011)

#23

Post by dfox »

hazeii wrote: post #19
imron wrote: post #17

Earlier quoted context omitted.

> 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.

Really? No longer an MS user but occasionally my code gets ported to Windows so would like to know more.

MSVC in C mode is essentially C89 plus extensions needed to compile C++/C99-isms present in Windows SDK and DDK headers. And Microsoft seems to be mostly interested in whether the compiler is able to build NT kernel and drivers and nothing much else.

Re: To become a good C programmer (2011)

#24

Post by fao_ »

It's unfortunate he doesn't list the POSIX system interface, which has personally become an absolute boon:

https://pubs.opengroup.org/onlinepubs/9699919799/

You can search it using duckduckgo with !posix, too.

Something else I've found infinitely useful when digging into musl libc or doing assembly programming, is the SYSV x64 ABI: https://refspecs.linuxfoundation.org/elf/x86_64-SysV-psABI.p...

Re: To become a good C programmer (2011)

#26

Post by Touche »

commandlinefan wrote: post #9

> 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.

Re: To become a good C programmer (2011)

#27

Post by madmax96 »

pmiller2 wrote: post #15

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?

I believe GCC does support all of C99 and has for a while. https://gcc.gnu.org/c99status.html

Re: To become a good C programmer (2011)

#28

Post by wwweston »

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 becoming a good C programmer? Especially in a time where Rust and Go are viable options?

Re: To become a good C programmer (2011)

#29

Post by zelly »

imron wrote: post #17
ternaryoperator wrote: post #12

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.

You can use clang on VS

Re: To become a good C programmer (2011)

#30

Post by xscott »

hazeii wrote: post #18
ternaryoperator wrote: post #12

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…

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 argument to be had over size_t vs ssize_t, but that can wait :-)
Post reply on HN