[HN Gopher] To become a good C programmer (2011)
___________________________________________________________________
To become a good C programmer (2011)
Author : 6581
Score : 119 points
Date : 2020-02-14 09:09 UTC (13 hours ago)
(HTM) web link (fabiensanglard.net)
(TXT) w3m dump (fabiensanglard.net)
| pmiller2 wrote:
| 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?
| madmax96 wrote:
| I believe GCC does support all of C99 and has for a while.
| https://gcc.gnu.org/c99status.html
| steveklabnik wrote:
| Visual Studio is another one:
| https://stackoverflow.com/questions/48615184/does-visual-stu...
| wwweston wrote:
| 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?
| jason0597 wrote:
| 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.
| ternaryoperator wrote:
| 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 important to move past C89 to at least C99.
| I realize in 2011 (the date of this post), that was less
| feasible. But today, there is little reason for most projects not
| use the advances found in C99.
| fao_ wrote:
| > 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)
| imron wrote:
| > 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.
| zelly wrote:
| You can use clang on VS
| hazeii wrote:
| Really? No longer an MS user but occasionally my code gets
| ported to Windows so would like to know more.
| dfox wrote:
| 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.
| hazeii wrote:
| 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).
| VonChair wrote:
| I think it's important to push forward with getting people
| out of bad habits. In a lot of cases, the only way to do that
| is to force it. I don't often agree with things Apple does,
| but their forcing people to use x64 is similar to this I
| think.
| xscott wrote:
| 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 :-)
| madmax96 wrote:
| 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...
| fabiensanglard wrote:
| 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.
| sandov wrote:
| Have you read "C Programming: A modern approach" (2nd ed)? And
| if so, what do you think about it?
| fao_ wrote:
| 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...
| stebann wrote:
| This is a good list because it isn't a gigantic compendium about
| C.
| kuharich wrote:
| Prior discussion: https://news.ycombinator.com/item?id=11606296
| anaphor wrote:
| "C Interfaces and Implementations" is another one that comes
| highly recommended.
|
| https://sites.google.com/site/cinterfacesimplementations/
| fredsanford wrote:
| I consider [0] to be well written and fairly low fat.
|
| 0 https://github.com/Genymobile/scrcpy
| sandov wrote:
| I think you pasted the wrong URL.
| yesenadam wrote:
| 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-written?
|
| Also, am learning about writing APIs, any good books or talks
| about that people could recommend, or examples of particularly
| good ones in C? (I'm particularly interested in maths/graphics-
| type stuff.) Thanks!
| eindiran wrote:
| 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
| fabiensanglard wrote:
| I recommend git source code which was pretty neat last time i
| checked.
| jraph wrote:
| I find the source code of the Netsurf browser really beautiful:
|
| - https://netsurf-browser.org/
|
| - https://source.netsurf-browser.org/netsurf.git/tree/
|
| Including the sub projects, for instance:
|
| - https://source.netsurf-browser.org/libcss.git/tree/
|
| - https://source.netsurf-browser.org/libdom.git/tree/
|
| It feels immediately obvious and understandable, which is quite
| impressive for a browser. Everything is well documented, well
| separated, the code is clean and seems simple, functions are
| small, etc. I am really impressed. I'd want to work on such
| code. I have never worked on it though, and I am not connected
| in any way to this project.
| rhoyerboat wrote:
| recently I started working on a module for nginx and have
| developed a full-blown crush on the module loader and its
| relationship with core functionality. haven't seen anything
| else quite like it, in C, that is. major newb talkin'
|
| also plan9, its nice to read some kernel code that hasn't been
| tortured by practical requirements for decades.
| atq2119 wrote:
| The core Linux kernel is well-known and mostly well-written C.
| ndesaulniers wrote:
| 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.
| commandlinefan wrote:
| > No website is as good as a good book
|
| Good (and often forgotten) advice for more than just C...
| Touche wrote:
| 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.
| jasonjei wrote:
| 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 dynamic memory allocation.
| aphextron wrote:
| 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.
| Timpy wrote:
| > It is all you need to know about C...for the first few weeks.
|
| It seems the author was aware of this. Isn't syntax a good
| place to start for a new language?
| fabiensanglard wrote:
| In short: It is a great starter. The book is so tiny it won't
| discourage people and get them going in no time.
___________________________________________________________________
(page generated 2020-02-14 23:00 UTC)