Appendix H — When you have learned it all and still cannot build anything
There is a wall those who finish this book run into most often.
“ I have learned all of C. And yet when I try to build something, I can do nothing at all. What did I learn wrong? ”
★ Nothing was learned wrong. The next thing to learn simply is not C. Without that one line, people buy another grammar book, still cannot build anything, and blame themselves. This appendix is for choosing a road from that spot.
Why — what standard C does not give you#
chapter 66 called the standard library thin. In numbers: the standard settles thirty-one headers, and counting every function in them comes to a little over five hundred (appendix F carries them all).
And what is not in there is what this wall is made of.
| What you want to do | What standard C gives |
|---|---|
| open a window and press a button | nothing |
| make a sound | nothing |
| send and receive over a network | nothing |
| draw, or read an image | nothing |
| walk a directory | nothing — opening one file is as far as the standard goes |
| run several strands at once | C11′s <threads.h> exists, but it is optional |
| know the current time | yes (chapter 79) |
Table 105.1 — What standard C does not have
★ The accurate diagnosis is not “it has nothing” but it has nothing that touches the outside world. Standard C answers as far as computing, and reading and writing files. Screen, sound, network and devices all belong to the operating system or to libraries other people made.
This is design, not defect. As chapter 66 showed, C aimed at places where there might be no operating system at all, so it narrowed to “the least that can exist anywhere”. Richness was given up and portability gained.
What standard C alone can still finish#
“So can nothing be built with standard C alone?” No — and since that misreading is fairly widespread, it is worth stating.
| What | What it is good for |
|---|---|
| a text filter | counting lines and words, substituting, sorting, extracting — this is what the Unix tools always were |
| a reader for a data format | CSV, INI, simple configuration files. Good practice in parsing and error handling |
| a calculator or small interpreter | read an expression, give an answer. Recursive descent |
| a data-structure library | lists, hash tables, trees. chapter 97 is the real thing |
| tools that work on files | comparing, finding duplicates, checksums |
| a small library with tests | where chapters 102–103 actually get used |
Table 105.2 — What can be finished with standard C alone
★ These can be finished today with no platform knowledge. And every one of them uses only what this book taught — streams, strings, memory management, contracts, tests. A good part of “I cannot build anything” is really “I cannot decide what to build”.
What the gap really is — not a matter of skill in C#
But the moment you try to open a window or use a network, the wall arrives. Naming that wall accurately matters.
| It is easy to think | In fact |
|---|---|
| “I have not learned enough C” | you have learned C. What you do not know is that platform |
| “I need one more grammar book” | a grammar book has no way to open a window. Nor will it ever |
| “I am unusually bad at this” | everyone stops here. A language and a platform were always separate things |
| “it is because C is old” | opening a window in Python is learning a toolkit too. It merely arrives bundled there |
Table 105.3 — Between what and what does the gap lie
★ So the next step is not “more C” but choosing what to put on top of it. And that choice sets the next several months.
This book will not make the choice for you. It can, though, set down what the roads are and what each one costs.
Four roads — what else must be learned#
| Road | What else you learn | Character |
|---|---|---|
| Unix and Linux systems | the POSIX API — processes, file descriptors, signals, sockets, threads | closest to C. Overwhelmingly the most material, and the kernel and tools are all C |
| embedded | the chip’s datasheet, registers, interrupts, cross-compiling | where C is irreplaceable. chapter 104 covers those tools |
| Windows | the Win32 API — windows, the message loop, handles | made to be called from C and documented in C shape. But today’s desktop mainstream has moved to C++ and the languages above it |
| foundational software | the theory of the field — databases, drivers, kernels, codecs | few positions, but places where nothing but C will do. Getting in means knowing the field |
Table 105.4 — The roads that lead on from C
The first two have the widest doors. The Unix side is well organised (there is a standard, POSIX), and for the embedded side chapter 104 shows the entrance.
Q. Which of the four should I choose?
A. This book does not answer that. It gives only criteria for choosing.
- Choose what is within reach. With a Linux machine to hand the Unix door is nearer; with a board already bought, the embedded one. Choosing while imagining an environment you do not have means never starting.
- Choose where the result is visible. A window appearing, an LED blinking — these have a power to keep you going. Early on that matters more than skill.
- Check whether material exists in your own language. Whether you can search when stuck is what decides your pace.
★ And one is enough. Going to the end of one beats skimming all four — live through one platform properly and the next is learned far faster.
One window on the screen — roads to a GUI#
This is the question that comes up most: “how do I open a window in C?” The answer divides by what you put on top. Four of them, sorted by character.
| What | Character | What it costs |
|---|---|---|
| Win32 (the Windows API) | the floor of Windows. Made to be called from C, documented in C shape | Windows only. Even one window takes real work |
| GTK | the mainstream toolkit of the Linux desktop, and the library itself is written in C | you must also learn an object system, GObject |
| SDL, Raylib | a thin wrapper over window, input and drawing. The games and visualisation side | no widgets — you draw the buttons yourself |
| single-file UI | things like Nuklear and microui that come as one source file | very small, but the drawing itself is yours to attach |
Table 105.5 — Roads to opening a window in C
The criteria for choosing follow from that character.
- For an ordinary program with buttons and text fields, the operating system’s toolkit (Win32, GTK) is right.
- For a screen you draw entirely yourself (a game, a visualisation, an instrument panel), SDL or Raylib gets there far faster.
- To add as little as possible, put a single-file UI on top and leave the drawing to one of the above.
★ One thing is met on every road — the event loop. The program stops flowing top to bottom and becomes something called upon whenever something happens. It is the same kind of inversion as “the handler only raises a flag; the real work happens in the main flow” in chapter 81, so rereading that chapter makes it less strange.
What to build#
“Go and build a project” is no help. Here they are set down so you can choose. What must be learned grows from top to bottom.
| What you build | What you learn | In this book | Where you get stuck |
|---|---|---|---|
| a text filter | streams, reading line by line, handling strings | chapters 68 and 70 | line endings and encodings (chapter 8) |
| a CSV or INI reader | parsing, returning errors as values | chapters 44 and 53 | exceptions like quoting and escapes |
| a calculator or small interpreter | recursive descent, data structures, lifetimes | chapters 39 and 46 | who owns the memory |
| a duplicate-file finder | hashing, large inputs, walking directories | chapter 89 | ★ walking a directory is already the platform |
| a small library with tests | public headers, golden tests, gates | chapters 102–103 | deciding what to make public |
| opening one window | the event loop, attaching someone else’s library | the section above | wiring a library into the build |
Table 105.6 — Things worth building to the end
★ The first five finish with no platform knowledge. The sixth is where the gap is first crossed. So if an order is to be recommended: finish one small thing, then go out to the platform. Only with something finished behind you can you tell, when the platform blocks you, “what I cannot do” from “what is hard in itself”.
★ If you need more to choose from, there is a list that gathers only “learn by building” guides (Project Based Learning, Table 105.9 below). Its C/C++ entry is the largest one there, and a shell, a text editor and a hash table are all written to be followed from start to finish.
Counter-example. Starting with the big thing
“I will write an operating system”, “I will write a database” — the resolve is admirable, and it almost always stops halfway. The stopping point is usually the same: where the interesting part (design) ends and the tedious part (error handling, portability, tests) begins.
And the tedious part is exactly what this book has been about throughout. So the recommended order is the reverse — pick something small enough to finish and build it including every error path; it leaves far more behind than half-building something large.
The large thing can wait. By then you will start it knowing in your body how long what takes.
Where to learn#
Books, online references and practice sites are gathered in appendix D. Here are only the ones that fit the place this book leaves you, sorted by character.
★ The addresses were chosen to last, but places on the internet move in the end. If a link is dead, search by name — every one below is widely known by its name.
Going deeper into C#
| What | Where | Character and caveats |
|---|---|---|
| 씹어먹는 C 언어 (Chewing on C) | modoocode.com/231 | a C course in Korean. Its rule is “type every source example by hand”. Being able to search in your own language when stuck decides your pace |
| Beej’s Guide to C | beej.us/guide/bgc/ | a free guide to C alone, in HTML and PDF. ★ the author calls it beta, so where it and the standard disagree, follow the standard |
| Beej’s Guide to Network Programming | beej.us/guide/bgnet/ | the same author on sockets. ★ the most widely read piece of writing for a first step onto the Unix road |
| awesome-c | github.com/oz123/awesome-c | C libraries and tools gathered by category. Use it to survey “what is there for opening a window” |
Table 105.7 — Places to see more C
Seeing computer science widely#
| What | Where | Character and caveats |
|---|---|---|
| CS50 (Harvard) | cs50.harvard.edu/x/ | ★ it starts in C and goes on to Python, SQL and the web. Free as open courseware. A good fit for widening the view after this book |
| MIT OpenCourseWare | ocw.mit.edu | university courses published openly. The operating-systems and computation-structures courses meet the place this book leaves you |
| Georgia Tech OMSCS open courseware | sites.gatech.edu/omscsopencourseware/ | some forty graduate courses published — operating systems, computer architecture, embedded optimisation. ★ lectures and exercises only; assignments and exams are not included |
| K-MOOC | kmooc.kr | Korean university courses published by the Ministry of Education. Heard in Korean |
| OSSU Computer Science | github.com/ossu/computer-science | a curriculum that follows an undergraduate course of study using open lectures alone. ★ it is not light — reckon on twenty hours a week for about two years. Hard to endure alone, so find people to go with |
Table 105.8 — Courses and curricula
Guides and lists#
These are what you open when you do not even know what exists. Every one is a list rather than a text, so after choosing here you must still take hold of one thing and go to the end of it.
| What | Where | Character and caveats |
|---|---|---|
| Free Programming Books | github.com/EbookFoundation/free-programming-books | a large list of freely readable books and courses by language. There is a separate Korean list. ★ being a list, quality is uneven — appendix D has the eye for choosing |
| roadmap.sh | roadmap.sh | what to learn in each field, drawn as pictures. Good for surveying “what to do next”. ★ a guide only — there is no depth in it |
| Awesome | github.com/sindresorhus/awesome | a list of lists, gathering “awesome lists” by topic. What actually serves a C reader is awesome-c inside it |
| Project Based Learning | github.com/practical-tutorials/project-based-learning | Guides that build something, gathered by language. The C/C++ entry is the largest in the list — a shell, a text editor, a hash table, an allocator, a virtual machine, each written to be followed start to finish. ★ But operating systems, kernels and databases sit right beside them — the trap warned about just above, so pick the small ones from this list |
| Coding Interview University | github.com/jwasham/coding-interview-university | ★ a different kind of thing. A study plan aimed at job interviews, so its purpose differs from this appendix’s “what to build”. Open it only when an interview is in front of you |
Table 105.9 — Places to survey what exists
★ Course or list, this book’s one criterion holds: does it make your hands move? A course only listened to and a list only skimmed help little here. The grammar is already known; what is needed is not explanation but the experience of being stuck and getting out.
Q. Having read this book, am I now “intermediate”?
A. Such a scale is of little use. The more useful question is this — is there anything you have built to the end by yourself?
This book covered the language and its contracts, and the way several people build together. That is the floor, and a firm floor means less wobble whichever road you take (it is what chapter 1 promised). But a floor is not a building. Until you have stood one thing up to the end, there is no way to know how far apart knowing and being able to do lie.
So this appendix ends in one line — pick one small thing and finish it, error paths and all. What to learn after that will show itself.