Not a bad summary. Albeit with some odd choices.<p>[EDIT: Reading a little more I'm revising down as summary. There's quite a bit that's amazingly tortuously explained, or slightly wrong. e.g. '//' doesn't have to be the first 2 chars of a line, it's <i>anywhere</i> to EOL. He refers to both parentheses and braces as braces! Explanation of needing ';' at EOL is not helping any beginner who;d be better off with the traditional "all C statements end with a ';'".]<p>Couldn't call it a primer though as it takes an express trip through the features from my first program to pointers to functions in a dozen page downs.<p>I don't think "downside of function pointers is the added mental load to handle the indirection" rates as enough of a warning, at all. How's about letting our beginners trip up on arrays and pointer arithmetic, in a few example programs, before giving keys to <i>all</i> the self inflicted weaponary?<p><i>"void An undefined type, used often to mean no type (no return or no parameters) or if used with pointers, a pointer to “anything”</i><p>Undefined? That strikes me as a way for the beginner to get totally the wrong idea.<p>It's used to indicate no return value or parameters in function definitions. A void pointer is generic - it can be cast implicitly to anything. You can't do pointer operations until it has been cast to a type. It is <i>not</i> undefined.
"In C an array is generally just a pointer to the first element."<p>No, arrays are not pointers.<p>"A String is generally a pointer to a series of bytes (chars) which ends in a byte value of 0 to indicate the end of the string."<p>No, a string is by definition "a contiguous sequence of characters terminated by and including the first null
character". It is not in any sense a pointer.<p>Anyone who things arrays or strings are "really" just pointers should not be writing C tutorials.<p>(See section 6 of the comp.lang.c FAQ, <a href="http://www.c-faq.com/" rel="nofollow">http://www.c-faq.com/</a> .)
It's been way too long since I've learned C for me to put myself in the shoes of somebody attempting to learn it for the first time but it's a bit steep for a "primer", isn't it? I mean just looking at the examples it goes from introducing structs to a complex examples dealing with malloc, free, enums, pointers, NULL, arrays and for loops.<p>I also think the section about "the machine" is interesting but it's a bad idea in a C tutorial. When you code C you code for the C abstract machine, not your CPU. It's very important to understand that difference, especially if you want to write portable code. For instance integer overflow is most likely very well defined on your machine, but it's not in the C virtual machine. C is not a macroassembler. Furthermore I really don't think the details in this sections are relevant in the early stages of learning C.<p>There also are a few technical inaccuracies:<p>>So bytes (chars) can go from -128 to 127, shorts from -32768 to 32767, and so on. By default all of the types are signed (except pointers) UNLESS you put an “unsigned” in front of them.<p>That's true on most systems but "char" can be either signed or unsigned (IIRC on ARM they default to unsigned) and the C standard only gives minimum ranges, so 32bit chars and 64bit shorts are theoretically possible (and can occur on systems where the smallest addressable value is larger than 8 bit such as some DSPs). It's pure nitpick of course but why even bother mentioning that in a C intro? Introduce stdint.h instead, that's actually very useful for any C coder.<p>>You can have a pointer to pointers, so de-reference a pointer to pointers to get the place in memory where the actual data is then de-reference that again to get the data itself<p>>So keep this in mind as a general rule - your data must be aligned.<p>>Note that in addition to memory, CPUs will have “temporary local registers” that are directly inside the CPU.<p>Are we seriously talking about nested pointers, alignment and CPU registers before we've even introduced printf? If a newbie manages to get past that and continue through the examples I congratulate them.<p>I don't want to sound too harsh, it's definitely very commendable to try and share your knowledge with other people and writing tutorials is very time consuming and not always very rewarding. That being said I definitely wouldn't advise anybody to start learning C using that document, especially since there's already a wealth of resources for learning C, both online and off.
I have mixed feelings about this, since it's got a lot of great information for someone getting started with C. I can see why you'd want to avoid scattering dire warnings all over the place, but it skips blithely past a whole host of hazards, stopping briefly only to mention that synchronization can be a cause of threading bugs. It's leading people down the garden path, and then leaving them at the bottom where there's a hungry tiger.
Whenever I was trying to learn C (and as ever making small bits of progress), what I always wanted was a great visualisation system for pointers. I've seen various attempts at this online but I've never really found something that felt intuitive. I think a good on-paper means of reasoning about pointers would be a huge help in becoming fluent in C.
A little light on pointers, considering how important they are and what a conceptual stumbling block they can be.<p>I wrote C/C++ for years in a scientific setting and didn't completely conquer the damn things until I had to write some assembly for a hobby project.
It's interesting that this is from the enlightenment website. It's been years since I tried their desktop/window manager. Glad to see they are still around.
See also: Summary of the "C" language (<a href="https://www.csee.umbc.edu/courses/undergraduate/CMSC104/spring02/burt/C_summary.html" rel="nofollow">https://www.csee.umbc.edu/courses/undergraduate/CMSC104/spri...</a>)
Great introduction for a beginner.
C remains my favorite programming language, even after all these years. It's one of the most simple languages, yet also very powerful. Yes, it is easy to make horrible bugs- but that's the price you pay for speed.
This is great, wish I'd seen something like this when I was first interested in C. Most introductions are afraid to go into anything complicated, which is ultimately patronising to a reader and doesn't help in the long term.
Incidentally, a long time ago I was looking for GUI libraries under Linux, and looked at Enlightenment code. I was very, very impressed. I expected a mess, because Enlightenment was mostly (superficially) known as a fancy window manager with all the doodads, bells, and whistles. What I found instead were cleanly structured libraries with great concepts and nice C code.
I often find tutorials about C language miss details about standard object-oriented programming with C. How to do inheritance, type checking, fields and methods, ref counting and so on. The practices are used in almost any C software today but rarely covered systematically.
This is the kind of article that touches on so many issues and aspects, not giving the experienced any new knowledge, while giving a fake sense of "completeness" to beginners, letting them build an overly simplified and artificial view.<p>You understand what linking is when you understand how addresses in machine code work, you understand the call stack when you understand the principal layout of variables in memory, etc.
C for people who know what EFL stands for. I believe I know C but I can’t for the life of me think of what EFL might mean. Yes I’ll google it but what does that say about this author?