Malcolm's new book

[Christopher Benson-Manica]

I did not cite these libraries as places to look for
good style or modern C.

My point is: typedef'ing structs is a wide practice.

If the practice is both widespread and stylistically questionable
(which you seem to be agreeing with), the statement in the book would
have been better phrased "It is common practice to typedef structs,
but it is not considered good style."

 

[Richard Heathfield]

Christopher Benson-Manica said:

If the practice is both widespread and stylistically questionable
(which you seem to be agreeing with), the statement in the book would
have been better phrased "It is common practice to typedef structs,
but it is not considered good style."

....except, of course, by those who consider it good style (myself
included).

 

[regis]

If the practice is both widespread and stylistically questionable
(which you seem to be agreeing with),

( No. I agreed that the typedef'ing of pointers to structs
was not a good idea. I personally always typedef structs with
the same name as the tag, the way it is done automatically in C++.)

the statement in the book would
have been better phrased "It is common practice to typedef structs,
but it is not considered good style."

( it's more a matter of nice/ugly than good/bad practice.
The latter vocable generally leads to unnecessary religious wars... )

 

[Christopher Benson-Manica]

( No. I agreed that the typedef'ing of pointers to structs
was not a good idea. I personally always typedef structs with
the same name as the tag, the way it is done automatically in C++.)

To each his own, but I'm not sure the C++ comparison is particularly
useful. <ot>A C++ struct is quite a different animal than a C

( it's more a matter of nice/ugly than good/bad practice.
The latter vocable generally leads to unnecessary religious wars... )

As much fun as burning heretics at the stake can be, you and Richard
are probably right.

 

[REH]

To each his own, but I'm not sure the C++ comparison is particularly
useful. <ot>A C++ struct is quite a different animal than a C
one.</ot>

Actually, if you define a struct in C++ the same as you do in C, it is
guaranteed to be equivalent to the C version.

 

[Malcolm McLean]

Congratulations! Your books provide a shiny, lucid example on how
books ought not to be written. Please keep up the good work.

What a nasty little man you are. Everyone else has contributed something
positive, even it is only spotting a typo, but you just have spiteful things
to say.

 

[Christopher Benson-Manica]

What a nasty little man you are. Everyone else has contributed something
positive, even it is only spotting a typo, but you just have spiteful things
to say.

I do hope you will take the time to acknowledge those positive
contributions.

 

[Richard Heathfield]

Malcolm McLean said:

What a nasty little man you are. Everyone else has contributed
something positive, even it is only spotting a typo, but you just have
spiteful things to say.

Malcolm, if that is the worst crit you ever get, count yourself
thrice-blessed. Critcritters can get a lot nastier than that.

 

[Malcolm McLean]

I don't have too much of a problem with a C book defining and using
terms like "procedure" and "pure function", as long as it (a) defines
them clearly, (b) defines them in ways that don't conflict too badly
with common usage, and (c) make it very clear that the terms are being
defined by the book, not by the C standard.

It could also be argued that a C book should just use the terminology
defined by the standard, but Malcolm's book isn't really *about* C;
it's primarily about algorithms, using C to present them. In that
context, distinguishing "procedures" and "pure functions" from other
functions is probably sensible.

The question is whether to use an existing word or coin a new one.

For my purposes

int foo(void)

and

void foo(int *ret)

don't have any really important differences. From a compiler writer's point
of view, of course, it is important that if(foo()) is legal whilst
if(foo(&x)) is not.
Similalry from an algorithms point of view we are not too interested in
whether a function receives its parameters as arguements or in globals.
Under the bonnet a lot of compilers implement globals with a pointer that is
in scope for every function, anyway.

So the important difference is between code which calculates something, and
code which does something. You could stretch the point by saying that flow
control is a third class of code, but that can probably be ignored.

"Function" is the accepted mathematical term for a mapping of input to
output, which is what a calculation is, so I can use it. "Procedure" isn't
firmed up, largely because the word is used in so many different ways.
However it has the English meaning of a "series of actions". Given that I'd
decided not to coin my own words, procedure seems the best choice for a
subroutine that isn't only a function. Procedures can call functions, but
functions cannot call procedures.

But I've never heard of the term "procedure" being defined in terms of
I/O. Normally a "procedure" would be what C calls a function
returning void. A lot of C functions also have a primary purpose of
causing side effects, but return a result that indicates whether it
succeeded or not; some other languages might, for example, use a
procedure that raises an exception on failure. (qsort() is a good
example.)

That's my use. An "action" is IO, if you think about it. Everything else is
just shuffling bits about in memory.

 

[Malcolm McLean]

Given the amount of criticism raised so far, would you comment on how the
book was edited and reviewed.

Most posters have been negative, but mainly it's been trivia - a few typing
errors, one actual buggy line. They somethimes invest huge significance in
this - "why write a book for which you are not qualified". In fact it would
be a miracle if not a single error crept into a 600 page book.

The brave new world of the internet disintermediates. That's why the book
costs sixteen pounds instead of the thirty to fifty you'd pay for the same
thing in a bookshop. The loss of a professional editor - it was done by me
and the artist, who is a non-programmer - is a double-edged sword. It means
you have more immediate contact with the the mind of the author, but it also
means that somethings that maybe should have been blue pencilled stay in.
It's too early in the internet publishing game to say how it will pan out.

The other factor, as someone else mentioned, is that I can make changes
quite easily. Unfortunately the tools are not quite there yet. For instance
the web pages were saved by Open Office, and it didn't make a very good job
of formatting the code. If I reformatted it all by hands inevitably you get
more typos. Then each change would ahve to be synchronised with two
versions. However I might go down that route, since the webpages are the
place most potential purchasers will probably land on first.

 

[regis]

Most posters have been negative, but mainly it's been trivia - a few
typing errors, one actual buggy line. They somethimes invest huge
significance in this - "why write a book for which you are not
qualified". In fact it would be a miracle if not a single error crept
into a 600 page book.

There is one error that is neither typographic or programmatic.
it's a marketting one: In no bookstore you will see
"Basic Algorithms" on the same shelf as
"12 common atheist arguments (refuted)"...

 

[Keith Thompson]

"Function" is the accepted mathematical term for a mapping of input to
output, which is what a calculation is, so I can use it. "Procedure"
isn't firmed up, largely because the word is used in so many different
ways. However it has the English meaning of a "series of
actions". Given that I'd decided not to coin my own words, procedure
seems the best choice for a subroutine that isn't only a
function. Procedures can call functions, but functions cannot call
procedures.

[...]

Not coining your own word is fine. Coining your own meaning for an
existing word, IMHO, only causes confusion.

 

[Keith Thompson]

The other factor, as someone else mentioned, is that I can make changes
quite easily. Unfortunately the tools are not quite there yet. For instance
the web pages were saved by Open Office, and it didn't make a very good job
of formatting the code. If I reformatted it all by hands inevitably you get
more typos. Then each change would ahve to be synchronised with two
versions. However I might go down that route, since the webpages are the
place most potential purchasers will probably land on first.

If I were going to write a book on C, I'd maintain all the C sources
separately, and import them into whatever word processing program I'd
use, so the question wouldn't arise. And I'd never include a code
sample in a published work unless I had actually compiled and executed
it. Logical errors happen, as do typos in English text, and they're
difficult to avoid. Most typos in actual code can be avoided.

If you're stuck with exporting your C source code from Open Office,
run it through "indent" or some similar tool rather than trying to
reformat it by hand.

 

[Eric Sosman]

The question is whether to use an existing word or coin a new one.

... or whether not to bother at all, since the distinction
between "method" and "section" is meaningless in C.

For my purposes

int foo(void)

and

void foo(int *ret)

don't have any really important differences. From a compiler writer's
point of view, of course, it is important that if(foo()) is legal whilst
if(foo(&x)) is not.

Not a special case, nor an essential difference between a
void-valued function and an other-valued one. For example,
consider that

struct bar baz(void);
if (baz()) ...

.... is also invalid, even though baz returns a value. It is
not the void-ness or void-not of a function that determines
whether its returned value can be used in an `if' (or assigned
to a variable, or whatever), but the type of the returned value.
A void-valued function is illegal in some contexts; a struct-
valued function is illegal in some contexts; an int-valued
function is illegal in some contexts. It's the type that makes
the difference, not the void-ness.

Similalry from an algorithms point of view we are not too interested in
whether a function receives its parameters as arguements or in globals.
Under the bonnet a lot of compilers implement globals with a pointer
that is in scope for every function, anyway.

I've never encountered one that does so, no, not even once --
but I've encountered somewhat fewer than all compilers. No doubt
you're right, and the world is full of "a lot" of weird compilers.
(It would go some way towards explaining your ideas about C.)

So the important difference is between code which calculates something,
and code which does something. You could stretch the point by saying
that flow control is a third class of code, but that can probably be
ignored.

Why is this difference "important?" Why is it even "the least
bit important?" It's a pointless digression in the book, that's
all. You should consider removing it from the second printing.

"Function" is the accepted mathematical term for a mapping of input to
output, which is what a calculation is, so I can use it. "Procedure"
isn't firmed up, largely because the word is used in so many different
ways. However it has the English meaning of a "series of actions". Given
that I'd decided not to coin my own words, procedure seems the best
choice for a subroutine that isn't only a function. Procedures can call
functions, but functions cannot call procedures.

Since "procedure isn't firmed up," you can say whatever you
like about it without advancing the discussion.

(Your text offers strlen() as an example of a "function," but
by your definition it isn't one, or at any rate needn't be one.)

That's my use. An "action" is IO, if you think about it. Everything else
is just shuffling bits about in memory.

http://en.wikipedia.org/wiki/Begging_the_question

 

[Eric Sosman]

If the practice is both widespread and stylistically questionable
(which you seem to be agreeing with), the statement in the book would
have been better phrased "It is common practice to typedef structs,
but it is not considered good style."

Who died and made you Pope? ;-)

Personally, I typedef structs and unions, don't typedef data
pointers, and sometimes typedef function pointers. I'm not
promoting my style as a model for others to follow: make up your
own mind. But neither am I apologizing for it: who died and made
you Pope? Nor am I condemning people whose styles are different:
who died and made *me* Pope?

Consider for a moment that a professional programmer spends
far more time reading code written by other people than writing
original code of his own. (That is, after all, the fundamental
promise of "code re-use.") It follows that if you are convinced
you know the One Right Way to do things, your programming career
will be short and inglorious.

 

[Charlton Wilbur]

CBM> I do hope you will take the time to acknowledge those
CBM> positive contributions.

And either fix the errors at once or withdraw the book until they can
be fixed. There's no excuse for spreading incorrect information.

Charlton

 

[pete]

Keith Thompson wrote:

But I've never heard of the term "procedure" being defined in terms of
I/O. Normally a "procedure" would be what C calls a function
returning void. A lot of C functions also have a primary purpose of
causing side effects, but return a result that indicates whether it
succeeded or not; some other languages might, for example, use a
procedure that raises an exception on failure. (qsort() is a good
example.)

qsort is a good example of what?

 

[pete]

That's my use. An "action" is IO, if you think about it.
Everything else is
just shuffling bits about in memory.

I don't understand what you mean by either IO or "action".

All that qsort does, is to shuffle bits about in memory.

 

[Keith Thompson]

qsort is a good example of what?

Of me not paying sufficient attention before posting. (I had assumed
qsort returns a status result; in fact, it returns void. Any failure,
such as an inconsistent comparison function, invokes undefined
behavior.)

system() is a better example of what I was talking about.

 

[Christopher Benson-Manica]

Christopher Benson-Manica wrote:

Who died and made you Pope? ;-)

Clearly my *post* could have been better phrased; fortunately the text
will not be included in any book

(I'm glad it's Friday.)