
C Primer - chauhankiran
https://www.enlightenment.org/docs/c/start
======
oldcynic
Not a bad summary. Albeit with some odd choices.

[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 _anywhere_ 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 ';'".]

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.

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 _all_ the self inflicted weaponary?

 _" void An undefined type, used often to mean no type (no return or no
parameters) or if used with pointers, a pointer to “anything”_

Undefined? That strikes me as a way for the beginner to get totally the wrong
idea.

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

~~~
_kst_
"Explanation of needing ';' at EOL is not helping any beginner who'd be better
off with the traditional "all C statements end with a ';'".]"

Almost all C statements _and declarations_ end with a semicolon. But compound
statements don't.

~~~
oldcynic
Thanks. Missed 'individual'... Mind I'd stick with the K&R approach and refer
to compound statements as blocks in a beginner's primer. What I wouldn't do is
"explain" in a way that will probably have a beginner rescanning multiple
times - I had to do a double take:

"Other lines that are not starting a function, ending it or defining control
end every statement in C with a ; character"

------
_kst_
"In C an array is generally just a pointer to the first element."

No, arrays are not pointers.

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

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.

Anyone who things arrays or strings are "really" just pointers should not be
writing C tutorials.

(See section 6 of the comp.lang.c FAQ,
[http://www.c-faq.com/](http://www.c-faq.com/) .)

~~~
szemet
Ok. But I do not blame people who unify the two things, because C does not
really stress the difference.

On the contrary - even in small details, like for example the equivalence of
p[i] and * (p+i), so you can legally write 3[p] in C...(==p[3])

~~~
simias
It's because that C makes it easy to confuse the two concepts that it's very
important to stress when and how they're different.

What creates the confusion in C is that arrays try very hard to decay into
pointers at any occasion and on top of that you have "fake" arrays when
they're declared as function parameters (something that's probably the most
insane "feature" of C IMO. And don't get me started to the a[static n] syntax
that solves nothing and introduces even more confusion on top of adding yet an
other completely new meaning to the 'static' keyword). Most crucially they
behave very differently when it comes to using sizeof.

It's also very important to understand the difference to be able to understand
`const char _p = "abcd"` vs `char p[] = "abcd"` or `struct s { /_ ... _/ ;
char _data; }` vs. `struct s { /* ... */; char data[]; }`.

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

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.

There also are a few technical inaccuracies:

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

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.

>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

>So keep this in mind as a general rule - your data must be aligned.

>Note that in addition to memory, CPUs will have “temporary local registers”
that are directly inside the CPU.

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.

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.

~~~
tom_mellior
> Are we seriously talking about nested pointers, alignment and CPU registers
> before we've even introduced printf?

No, printf is introduced in the very first hello world example. But the
concept of format strings is not explained, nor are variadic functions, and no
documentation for printf is linked.

Also, the example

    
    
        #define MY_TITLE "Hello world"
     
        printf("This is: %n", MY_TITLE);
    

is really quite broken. %n needs and int* argument and _writes_ the number of
characters written so far to it. A string constant is not only of the wrong
type, even more importantly it is not writable (though not const).

Of course a modern compiler with -Wall would catch this, but the tutorial
never mentions any flags you might want to pass to your compiler...

~~~
jancsika
That has to be a typo where "%s" was meant.

~~~
jwilk
I'm curious how do you manage to confuse the two...

Oh, in the Dvorak layout, "n" and "s" are next to each other. Maybe that's
how.

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

~~~
loeg
> 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

Much like the enlightenment codebase itself, unfortunately. If you want to see
some quite bad C code, just check out the source.[0]

[0]:
[https://what.thedailywtf.com/topic/15001/enlightened](https://what.thedailywtf.com/topic/15001/enlightened)

~~~
sevensor
Wow. Glad I use Qt!

------
larkeith
Archive link:
[http://web.archive.org/web/20180504113302/https://www.enligh...](http://web.archive.org/web/20180504113302/https://www.enlightenment.org/docs/c/start)

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

~~~
ryl00
What about this analogy? You have a piece of paper with a street address on it
(the pointer value). You go to that street address (derefence the pointer),
open the mailbox, and inside is another piece of paper with what you're
actually looking for (like someone's name). For pointers to pointers, add
another level of indirection..

~~~
Vindicis
I don't think really anyone has difficulty understanding the concept of a
pointer. It's their usage that trips people up, and that most tutorials I've
seen gloss over, which is where all the confusion stems from.

~~~
ovao
Exactly. There is the concept and the syntax of pointers, and those are
relatively straightforward to understand. I gave up on learning C++ — twice —
when I was a kid because no book explained _why_ there are pointers. It’s all
very “a pointer points to something! Now on to the next chapter.” (The third
time was the charm, luckily.)

One simple example showing value semantics would’ve made it click for me, and
things only get more interesting when you talk about performance.

------
cup-of-tea
K&R is the C primer. Read the entire comp.lang.c FAQ for more advanced stuff.

~~~
AceJohnny2
I love the K&R, as a good example of a concise, well-explained, with
exercises, introduction to a language. I measure every other programming book
relative to K&R.

That said, I wish there was a 21st century update to the K&R book, to take
into account improvements made the _at least_ the C99 standard, maybe even
C11, update the programming style a bit to avoid some of the more egregious
risky behaviors (always use str _n_ cpy), and some coverage of the
preprocessor. All of which while still maintaining the clarity of the original
book.

~~~
_kst_
"always use strncpy"

I disagree; you should almost _never_ use strncpy. Its name implies that it's
a "safer" version of strcpy, but that's not what it is at all. If the target
array isn't big enough, it can easily end up not containing a null-terminated
string.

As it happens, I wrote about this a few years ago. [http://the-flat-trantor-
society.blogspot.com/2012/03/no-strn...](http://the-flat-trantor-
society.blogspot.com/2012/03/no-strncpy-is-not-safer-strcpy.html)

------
aap_
Alpha is certainly not big endian. And MIPS today is probably little endian
more frequently than big endian.

------
nategri
A little light on pointers, considering how important they are and what a
conceptual stumbling block they can be.

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.

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

~~~
zafiro17
I checked the link expressly to see if it had indeed come from the
Enlightenment Project. If you want an easy way to try it again, I recommend
Bodhi Linux, which packages Ubuntu fundamentals with a modified Enlightenment
Desktop. It amazes me every time I use it. So gorgeous, and resource intensive
(remember when Enlightenment was considered "heavy"? All the major DEs are far
heavier now).

------
mcsb1
Nostalgia... Rasterman was light years ahead of his time with enlightenment.
Same programmer's league as Torvalds and Bellard.

~~~
pjmlp
Then he went working for Tizen.

[https://what.thedailywtf.com/topic/15001/enlightened](https://what.thedailywtf.com/topic/15001/enlightened)

------
teddyh
See also: Summary of the "C" language
([https://www.csee.umbc.edu/courses/undergraduate/CMSC104/spri...](https://www.csee.umbc.edu/courses/undergraduate/CMSC104/spring02/burt/C_summary.html))

~~~
msla
It always amuses me which "names" some "people" put in "quotes", and if they
distinguish between "C" and C, or JAVA and Java. Probably some subtle
technical distinction a programmer wouldn't understand...

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

~~~
bluetomcat
I would consider it a very compressed summary of key terms and aspects and not
something to build knowledge from if you are a beginner. The trip to a healthy
understanding of all these concepts goes through a lot more detailed examples
while solving relevant problems and realising the motivations for the
existence of each concept.

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

------
known
Cute and in [http://archive.li/GRxiT](http://archive.li/GRxiT)

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

~~~
jimpudar
Some people would disagree with you...

[https://what.thedailywtf.com/topic/15001/enlightened](https://what.thedailywtf.com/topic/15001/enlightened)

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

~~~
klez
Color me interested. Where can I find a codebase that uses this? Especially
inheritance.

~~~
nshm
Like here [https://www.codeproject.com/articles/108830/inheritance-
and-...](https://www.codeproject.com/articles/108830/inheritance-and-
polymorphism-in-c). For examples of this you can check gnu tools like gcc or
gdb, or glib-based libraries or the kernel source.

------
gcb0
who still call a log significand a "mantissa"?

specially in a easy to understand the basics kind of article.

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

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.

~~~
ejanus
Yours is not ideal . There are always multiple paths , and none is perfect.
Let's all keep walking, mentors and mentees , noobies and experts .

BTW I understood the power stack when I tempted to code a language...

------
W4ldi
> int bobs

> struct sandwich

> enum filling

------
natch
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?

~~~
zafiro17
EFL are Enlightenment Fundamental Libraries - the underpinnings of the
Enlightenment Desktop Environment. And the author is writing on the
Enlightenment website: it's clearly intended for current developers/users of
Enlightenment, who would probably know what EFL stands for. So it doesn't say
anything about the author, who is writing for a known audience.

~~~
natch
Enlightenment Foundation Libraries?

