Comments requested: brief summary of C

[Adam Barr]

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.

If anyone is interested, please feel free to read it and send me
comments. Note that the material is copyrighted, this document is
provided for review only, and the ideas contained in any comments may
be used in the book, in whole or in part, with no rights granted to
the person who provided the comments. I will however acknowledge by
name (if desired) anyone who sends comments.

The information is in PDF form per my publisher's request, but if this
is a problem for anyone, email me and I can send it to you in plain
text.

The file is at

http://www.proudlyserving.com/language/c.pdf

I have written similar summaries for other languages and have or will
post them in the appropriate newsgroups.

Thank you.

- Adam Barr
(e-mail address removed)

 

[Richard Heathfield]

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.

It isn't.

 

[Nils Petter Vaskinn]

It isn't.

So the pdf is real? I've seen the same post to other language groups (with
their language substituted obviously) so I assumed this was some kind of
scam using a vulnerability either in a common browser or a common pdf
reader.

To the OP: You will get better feedback if you provide the text as plain
text or html so that people could cut and paste the text when they
respond. I found one sentence that could be clarified, but when I couldn't
cut and paste that sentence easily (seems your pdf has some flag that
disallows selecting text in acroread) I didn't make the effort to read
through all of it.

An int holds an integer value, which can be 2, 4 or 8 bytes depending on
the platform.

True because you used the word _can_ but those are not the only legal
sizes of int, wich somone might think after reading your sentence.

The value NULL is assigned to pointers to indicate that they point to
nothing.

Change that "is" to "can be". Your sentence could lead someone to believe
that assigning NULL is done automatically, which is not the case (though a
compiler _could_ choose to initialize all pointers to zero it's not
guaranteed to)

FWIW

 

[John L]

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.

"blanks space" is a typo (and it is white space, as indeed you
call it later on).

"Arithmetic is as expected, with expressions grouped using parenthesis"
contains a typo and is at best misleading.

"char pointers are often assigned to constant strings" seems backwards.

Discussion of ++ is unhelpfully spread out.

Comments are used long before they are explained.

"If argument1 is an array, it is followed with []" is backwards;
argument1 might be declared as a pointer. (Imho this can cause
problems but that is a separate rant.)

By "functions with arguments that are replaced", you mean macros.

Your discussions of strings and structs are not quite right.

In places even the English used seems slightly odd.

There are also some curious omissions: so far as I can see,
neither libraries nor headers are mentioned.

Now, that is from a few minutes flicking through the text,
not properly reading it in sequence. It looks, however,
if it has been written in much the same fashion: as a series
of loosely connected thoughts about C. To judge it properly,
though, one would need to understand its purpose and target
audience. Perhaps an annotated sample program, a more
tutorial introduction, or a more systematic summary would
be better ways. Look at Kernighan & Ritchie for examples
of these approaches.

Remember too that an experienced programmer familiar with
any of the Algol-like languages (is that flame bait?) can
probably *read* most C code at least well enough to get
the general impression of what is going on. If this is
your target reader, then your introduction to C can
be more concise and concentrate on oddities like = vs ==
and so on.

HTH.

John.

 

[j]

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.

If anyone is interested, please feel free to read it and send me
comments. Note that the material is copyrighted, this document is
provided for review only, and the ideas contained in any comments may
be used in the book, in whole or in part, with no rights granted to
the person who provided the comments. I will however acknowledge by
name (if desired) anyone who sends comments.

The information is in PDF form per my publisher's request, but if this
is a problem for anyone, email me and I can send it to you in plain
text.

The file is at

http://www.proudlyserving.com/language/c.pdf

``Statements in C end with a semi-colon ( ; ).''

No, not true. By that definition the following
qualifies as a statement:

int foo;

A declaration is _not_ a statement. Read 6.8 of c99.


``C treats all blanks space as equivalent, so line breaks
and indents are for readability only.''

So #define FOO 10
is the same as #defineFOO10 ?


``A single statement without the braces also counts as a
block of code.''

No, it counts as a single statement.


``A char holds a single byte. Single characters are
surrounded by single quotes, such as 'a' and 'x' .''

I think you should also mention that char is an integer type
and the character literals are of type int. Otherwise
your statement can be misleading.


``Strings are simply arrays of type char. By convention,
a string is terminated with a 0 value, written as a single
character '\0' .''

Not adequate enough. As the standard says:
``A string is a contiguous sequence of characters terminated
by and including the first null character.''


``(you could put a different character in the tenth byte,
but it would then not be a properly-terminated string
according to C conventions).''

It would not be a string whatsoever if there is no
null character.


``char pointers are often assigned to constant strings, for example
city = "Boston";

It is not assigned to ``constant'' strings(you should call it a string
literal). It is assigned the address that the string literal decays to.


``Pointers are also dereferenced with * , so *city is the first byte
pointed to by city . In fact, pointers and arrays are often used
interchangeably, and the first char in the city array could be
referenced as city[0] or *city .''

This might mistakingly lead someone to believe that
pointers and arrays are one in the same if you do not
expound further on their differences.


``Note that C does no checks for validity of pointers, so *city
will likely cause a crash if city is uninitialized, and name[20]
gives an undefined result if name is allocated as above with room
for only 10 chars .''

C? You mean C implementations?


``Pointer arithmetic is allowed and automatically compensates
for the size of the element pointed to.''

I would use ``object'' not ``element''


``More generally, array[n] is equivalent to *(array + n) and in
fact is defined as such.''

No it isn't. It is equivalent to *((array) + (n))
The added parens are important. If your method
was actually used then the following would
fail:

a[i, j];

Which would be equivalent to *(a + i, j)

Which would end up dereferencing the value of ``j''
as opposed to *((a) + (i, j))


``typedef struct _record {
int element1; char element2;
struct _record * next;
} record, * record_ptr;''

The standard says that identifiers that begin with an
underscore are always reserved for use as identifiers
with file scope.



``int array[20];
for (i = 0; i < 20; i++)
{ { code involving array; } }''


``i < sizeof array / sizeof array[0]''
is the more common convention



``Comments are denoted by // ;''

Only under c99 they are.
It doesn't matter if your c89/90 implementation
_happens_ to support them. That is, of course, if
portability is a concern.

 

[Richard Bos]

``Dogs have four legs.''

No, not true. By that definition a cat qualifies as a dog.

It's still not true. But since I have no desire to sponsor the OP's
business (and reputation, which without the help of c.l.c would've
suffered quite a blow) without getting some form of remuneration, I'm
certainly not going to help the commercial leech by telling him why.

Here's a comment he can put in his book, though: the writer of that PDF
is by no means competent enough to be teaching others the C language.

Richard

 

[CBFalconer]

.... snip ...

The information is in PDF form per my publisher's request, but if
this is a problem for anyone, email me and I can send it to you
in plain text.

The file is at

http://www.proudlyserving.com/language/c.pdf

I have written similar summaries for other languages and have or
will post them in the appropriate newsgroups.

Why don't you simply mount the text file within a zip for anyone
who wants it? Then all the normal tools, such as diff and grep
etc. will work on it.

 

[Richard Bos]

It (i.e. ``Statements in C end with a semi-colon ( ; ).'') is true
except for the degenerate case of an empty compound statement ("{}").

Wrong. And be a wise man - don't help the leech.

Richard

 

[Jeremy Yallop]

``Statements in C end with a semi-colon ( ; ).''

No, not true. By that definition the following
qualifies as a statement:

int foo;

``Dogs have four legs.''

No, not true. By that definition a cat qualifies as a dog.

Jeremy.

 

[Nils Petter Vaskinn]

Why don't you simply mount the text file within a zip for anyone
who wants it? Then all the normal tools, such as diff and grep
etc. will work on it.

The most probable reason seems to be that his publisher has the
(incorrect) idea that a pdf is safe from someone getting at the text. It
can't be to have the formatting because it sucks (unless something is
wrong with both acroread and ghostview)

 

[Jeremy Yallop]

It's still not true.

It (i.e. ``Statements in C end with a semi-colon ( ; ).'') is true
except for the degenerate case of an empty compound statement ("{}").

Jeremy.

 

[Eric Sosman]

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.
[...]

First sentence: "Statements in C end with a semi-colon (."
Incorrect, and "semicolon" is misspeleld.

Second sentence: "C treats all blanks [sic] space as equivalent.
so line breaks and indents are for readability only." Incorrect.

Third sentence: "Blocks of code are surrounded with braces, {
and }." Correct! Huzzah!

Fourth sentence: "A single statement without braces also counts
as a block." Either incorrect or meaningless; it's debatable.

Fifth sentence: "The basic data types in C are int and char."
Incorrect.

Sixth sentence: "An int holds an integer value, which can be
2, 4, or 8 bytes depending on the platform (none of the code here
depends on the exact length of an int)." Correct as far as it
goes, but incomplete.

Seventh sentence: "A char holds a single byte." Correct but
tautological.

... and so on. Not a promising start; I didn't read more than
a few sentences further. My general impression is that an honest
effort has been made, but that the author is not sufficiently
knowledgeable in his subject to avoid making simple errors.

(Don't feel too bad. I once took an introductory Java class
from a full Professor of Computer Science who got himself hopelessly
confused over Java's argument-passing semantics. The whole class
was sitting there trying to tell him he was completely wrong, but
nobody with a PhD was going to listen to a bunch of students ...)

 

[Jeremy Yallop]

Wrong.

Yes, sorry. A statement ends with either a semicolon or a (possibly
empty) brace-enclosed sequence of statements.

Jeremy.

 

[pete]

Adam Barr wrote:

http://www.proudlyserving.com/language/c.pdf

I have written similar summaries for other languages and have or will
post them in the appropriate newsgroups.

You call
c = 5
an assignment statement,
though it is clearly an assignment expression and not a statement.

The last paragraph of the page,
is not the best place to demonstrate that you have mastered
the use of the semicolon in the English language.

 

[Adam Barr]

Thanks for the comments so far. On the issue of PDF vs. plain text, as
I said I was requested to post it as PDF, but I'll email it as plain
text to anyone who would prefer it in that format (which I agree is
more useful).

- adam

 

[Leor Zolman]

Thanks for the comments so far. On the issue of PDF vs. plain text, as
I said I was requested to post it as PDF, but I'll email it as plain
text to anyone who would prefer it in that format (which I agree is
more useful).

- adam

You /might/ facilitate getting more critiques if you simply re-post the PDF
after unchecking the "Do not allow...selecting text and graphics" checkbox
in Acrobat's security settings during the "Save as" operation... thus
saving yourself the emailing effort.
-leor

..
Leor Zolman
BD Software
(e-mail address removed)
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

 

[Mark McIntyre]

respond. I found one sentence that could be clarified, but when I couldn't
cut and paste that sentence easily (seems your pdf has some flag that
disallows selecting text in acroread)

You may need a newer version of acroread - I can copy/paste fine using V5.0

 

[Mike Wahler]

Incorrect, and "semicolon" is misspeleld.

-Mike

 

[Nils Petter Vaskinn]

You may need a newer version of acroread - I can copy/paste fine using V5.0

Mine is V5.0 too. If we're talking about the same pdf file here. What os
are you running on? It may be an issue with RH9.

Crossposted and followups set to move this subthread out of clc.

 

[John Bode]

No mention of header files? main()?

It's like you've focused on a few random spelling rules in English,
but haven't described what a correct English sentence looks like.

I also recommend writing a short but complete C program (with at least
one subroutine to illustrate parameter passing conventions) and
annotating it.