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

Brushing up on operating systems and C programming

shubhro.com

Post reply on HN
Print view View original

71–80 of 89 posts

Re: Brushing up on operating systems and C programming

#71

Post by pksadiq »

teeray wrote: post #5

Can anyone recommend an intermediate to advanced C book? I feel like most C material I've been exposed to in the past lacks what a modern C project should have when it comes to best practices, code organization, build tools (should I use make for this, cmake, where does autotools fit? what about clang vs gcc?), linters (valgrind?), testing, etc. I recognize that much of this falls outside of C, but all of these tools…

I would recommend C: A Reference Manual (by Samuel P. Harbison and Guy L. Steele Jr.) along with K&R The C programming language.

C has lots of edges where it's easy for a beginner to make mistakes. Say for example the minimal range of a char is -127 to 127 (yes, C cares 1's complement machines) or 0 to 255. Not knowing this may result in a code working in one machine while broken on others. So learning the standard is a must, especially, the undefined behaviors.

Re: Brushing up on operating systems and C programming

#72

Post by FourSigma »

donkey-hotei wrote: post #38
FourSigma wrote: post #31

Earlier quoted context omitted.

I am currently going through this book. Any advice on how to extract the most value out of it?

Sure! I recommend sitting with the book, a pen, and a notebook at a cafe or wherever you like and write solutions to the practice problems you see sprinkled in each chapter as you read every single word. Then choose a few of the homework problems and do those, some will require a computer. Most of all, work through the labs and don't cheat yourself by looking at other (probably not very good) solutions posted online!…

Awesome! Thank you for the insight!

Re: Brushing up on operating systems and C programming

#73

Post by grawprog »

ramzyo wrote: post #70
keldaris wrote: post #67

Earlier quoted context omitted.

I do exactly the same thing whenever I write C/C++. Genuinely large projects aside, I see no compelling reason to waste your time with build systems. This approach is simple, easy to maintain and lets you get on with writing actual code.

Out of curiosity, why not use make for something so simple instead of a Shell script?

My thoughts are a shell is usually installed by default. Make may not be. This is only a guess. I'm not sure myself.

Re: Brushing up on operating systems and C programming

#74

Post by spatulon »

ramzyo wrote: post #70
keldaris wrote: post #67

Earlier quoted context omitted.

I do exactly the same thing whenever I write C/C++. Genuinely large projects aside, I see no compelling reason to waste your time with build systems. This approach is simple, easy to maintain and lets you get on with writing actual code.

Out of curiosity, why not use make for something so simple instead of a Shell script?

In my mind, shell scripts are simpler. I have no reason to need the extra complexity that make brings.

Also, I do a lot of programming on Windows, where GNU make would be another dependency to install. (Also, in my experience, make is slow on Windows, since they have to emulate fork()). I guess I could use Microsoft nmake, since I assume it's still installed along with Visual Studio, but again, batch files are simpler.

Re: Brushing up on operating systems and C programming

#75

Post by omilu »

spatulon wrote: post #61
earenndil wrote: post #35

Earlier quoted context omitted.

To answer your questions: * Clang vs gcc: doesn't really matter. Clang has slightly better compile times. GCC has really advanced but in some cases still has inferior warning/error messages. Best practice is not to really use GNU c features unless you want to. If you do want to, decide if you want to just use the subset supported by clang or the full shabang from gcc. Beyond that: if you want to support both, test on…

I like your thinking regarding using simpler build tools. I took this to the extreme and now my build tool for personal C/C++ projects is just a file called build.sh/build.bat. That does little more than: gcc main.c main.c #includes any other .c files that are needed (the term for this appears to be a 'unity build'). Compiling this way is /really/ fast, which is why it's okay to use a dumb build script that always re…

did you watch handmade hero? he advocates the same

Re: Brushing up on operating systems and C programming

#76

Post by spatulon »

omilu wrote: post #75
spatulon wrote: post #61

Earlier quoted context omitted.

I like your thinking regarding using simpler build tools. I took this to the extreme and now my build tool for personal C/C++ projects is just a file called build.sh/build.bat. That does little more than: gcc main.c main.c #includes any other .c files that are needed (the term for this appears to be a 'unity build'). Compiling this way is /really/ fast, which is why it's okay to use a dumb build script that always re…

did you watch handmade hero? he advocates the same

Haha, yes. Casey has been quite a big influence on me re-finding enjoyment in programming that I thought I'd lost.

Re: Brushing up on operating systems and C programming

#77

Post by earenndil »

spatulon wrote: post #61
earenndil wrote: post #35

Earlier quoted context omitted.

To answer your questions: * Clang vs gcc: doesn't really matter. Clang has slightly better compile times. GCC has really advanced but in some cases still has inferior warning/error messages. Best practice is not to really use GNU c features unless you want to. If you do want to, decide if you want to just use the subset supported by clang or the full shabang from gcc. Beyond that: if you want to support both, test on…

I like your thinking regarding using simpler build tools. I took this to the extreme and now my build tool for personal C/C++ projects is just a file called build.sh/build.bat. That does little more than: gcc main.c main.c #includes any other .c files that are needed (the term for this appears to be a 'unity build'). Compiling this way is /really/ fast, which is why it's okay to use a dumb build script that always re…

I would tbh recommend make (bsd make is a wider-supported subset of gnu make) over a shell script, because it can automatically detect which source files need to be rebuilt and which can be kept from previous builds, greatly reducing compile times. Also, it supports parallel builds, although this one is relatively easy with a shellscript.

Re: Brushing up on operating systems and C programming

#78

Post by int_19h »

geokon wrote: post #68
gcd883 wrote: post #23

Earlier quoted context omitted.

I really enjoyed "Deep C Secrets" as an intermediate C book: Expert C Programming: Deep C Secrets https://www.amazon.com/dp/0131774298/ A little dated, still lots of relevant knowledge though.

What I liked about this book is that it's very upfront about how messed up C is. I read about half of it and it made me never want to write any C ever again. An especially memorable part for me was how it took 3 pages of language lawyering to explain why this doesn't compile: foo(const char **p) { } main(int argc, char **argv) { foo(argv); }

I don't see this as a good example of "how messed up C is". It doesn't compile because you're violating const correctness, and any other language with similarly sound correctness requirements would flag it in a similar way. If anything, this is one of those rare cases where C chooses correctness over convenience.

It takes quite a bit to explain because the "common sense" is that if one level of pointer indirection allows you to pass non-const where const is expected, then two levels shouldn't be any different. But common sense is wrong, and the compiler is right. And it doesn't require any language lawyering, either - all you need to do is slightly tweak the example to show why exactly it is unsafe.

Re: Brushing up on operating systems and C programming

#79

Post by int_19h »

earenndil wrote: post #77
spatulon wrote: post #61

Earlier quoted context omitted.

I like your thinking regarding using simpler build tools. I took this to the extreme and now my build tool for personal C/C++ projects is just a file called build.sh/build.bat. That does little more than: gcc main.c main.c #includes any other .c files that are needed (the term for this appears to be a 'unity build'). Compiling this way is /really/ fast, which is why it's okay to use a dumb build script that always re…

I would tbh recommend make (bsd make is a wider-supported subset of gnu make) over a shell script, because it can automatically detect which source files need to be rebuilt and which can be kept from previous builds, greatly reducing compile times. Also, it supports parallel builds, although this one is relatively easy with a shellscript.

If the sole purpose is to track which files changed, then redo is arguably a simpler solution to this problem - you don't need to learn a new language either (and its funky rules like the tab/space difference), just shell scripts with a couple new commands.

http://news.dieweltistgarnichtso.net/bin/redo-sh.html

Re: Brushing up on operating systems and C programming

#80

Post by int_19h »

spatulon wrote: post #74
ramzyo wrote: post #70

Earlier quoted context omitted.

Out of curiosity, why not use make for something so simple instead of a Shell script?

In my mind, shell scripts are simpler. I have no reason to need the extra complexity that make brings. Also, I do a lot of programming on Windows, where GNU make would be another dependency to install. (Also, in my experience, make is slow on Windows, since they have to emulate fork()). I guess I could use Microsoft nmake, since I assume it's still installed along with Visual Studio, but again, batch files are simple…

Take a look at this: http://news.dieweltistgarnichtso.net/bin/redo-sh.html

And for GNU tools on Windows, I would heavily recommend MSYS2 these days - having Pacman as the package manager is very nice, and there are already a lot of packages there.

Post reply on HN