Malcolm's new book

[Malcolm McLean]

The webpages for my new book are now up and running.

The book, Basic Algorithms, describes many of the fundamental algorithms
used in practical programming, with a bias towards graphics. It includes
mathematical routines from the basics up, including floating point
arithmetic, compression techniques, including the GIF and JPEG file formats,
hashing, red black trees, 3D and 3D graphics, colour spaces, machine
learning with neural networks, hidden Markov models, and fuzzy logic,
clustering, fast memory allocators, and expression parsing.

(Follow the links)

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Malcolm McLean]

"Eric Sosman" <Er*********@sun.comwrote in message
news:1186440511.431078@news1nwk...

Malcolm McLean wrote On 08/06/07 15:55,:
The book begins with a non-conforming implementation of
strlen(). It's kind enough to point out the nonconformity,
and goes on to provide a conforming replacement -- but one
wonders what purpose the bogus version serves, other than
to add thickness to the book.

The non-conforming implementation is an example of the book's style. It is
not written in C that happens to conform to the standards of the day, but in
C which I expect to still compile and work in a hundred years' time.

The book's implementation of mystrdup() compels a C99
compiler to emit diagnostics.

You repeat this several times. What you mean is that the function bodies are
given without headers. As you delve into deeper chapters you will soon see
why this is - text interspersed with code means that the headers make too
much visual mess without adding enough information content to justify
inclusion.
The problem is that by saying "a C99 compiler is compelled to emit
diagnostics" rather than "I think it would have been better to include
headers and prototypes" you really disqualify yourself as an objective
commentator.

At about this point, the text draws attention to some
coding conventions. Among them: the use of the identifier
`answer' to hold a function's return value. Oddly enough,
this mention is the last appearance of "answer" in the
chapter; the rest of the functions do not follow the
stated convention.

The convention applies for the whole book. "answer" isn't absolutely
uniform, but it is my normal choice for a variable to hold a return value.

>
There follows a peculiarity: A day-of-the-week function
that the author confesses he does not understand. The code
was "lifted from the net," says the book, but does not say
whether it was lifted from a reliable or from an unreliable
source. The text says it's all right to use a function you
don't understand, provided you "trust the author" -- but
since the author is unnamed, we do not have the means to
tell whether he is trustworthy.

Exactly. If you are doing very advanced programming then either you have to
be brillinat and encyclopedic, or you have to use code you don't understand.
Not an ideal situation, but it is very often necessary to do that.

>
The book next offers two macros (mentioning two more,
but not implementing them). The most obvious thing about
the book's macros is that their names consist entirely of
lower-case letters. While this is legal in C, it is far
more usual to name macros in upper-case -- some coding
standards, in fact, insist on this. The macros the book
offers aren't wrong, exactly, just in poor taste.

They are function-like macros. Unfortunately some of the arguments are
evaluated twice - a sng with the C macro system. I find lower case more
tasteful than upper

x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

The upper case gives the macro an emphasis it shouldn't have.

>
The chapter closes with an argument that putting code
in libraries that can be shared by many programs is a Bad
Thing; the "right" way to re-use code is to paste a copy
wherever you happen to need one. (No, I am not making this
up!) And just for laughs, the chapter ends with an English
error.

Cut and paste is generally a far superior method. Libraries are fine if you
are implemeting something fundamental like OpenGL, but not when you need a
list of dependencies in your code. No one wants to link in five libraries
all with conflicting definition of "bool" just to use a few string
functions.

>
Statistical summary of "Some Simple Functions:"

- Number of function implementations shown: ten

- Number of functions that require compile-time
diagnostics: five

- Number of functions with bugs (beyond required
diagnostics) spotted by this reader: four

Need to check those bugs.

>
- Number of functions with bugs known to the author
(but published anyhow): one

- Number of macro implementations shown: two

- Number of bad macro implementations shown: two

- Influence of this more extensive reading on the
reader's opinion of the book: negative

Thanks for the input.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Al Balmer]

On Mon, 06 Aug 2007 18:48:30 -0400, Eric Sosman <Er*********@sun.com>
wrote:

There follows an explanation of a procedure for finding
the date of Easter, credited to Gauss. This reader had not
heard of Gauss having worked on the problem, and finds it
hard to imagine that it would have interested Gauss: after
all, the best Gauss could hope to do with a formula already
in use would be to simplify it.

<OTOr develop a different formula. The Gaussian algorithm for
determining the date of Easter is actually quite well known. The story
is that he developed it in the course of determining his own birth
date, described by his mother as a Wednesday, eight days before
Ascension Day, which is forty days after Easter Sunday. </OT>

--
Al Balmer
Sun City, AZ

[pete]

Malcolm McLean wrote:

They are function-like macros. Unfortunately some of the arguments are
evaluated twice -

x = CLAMP(x, 0, 255);

The upper case gives the macro an emphasis it shouldn't have.

The upper case gives the macro an emphasis it *should* have,
*because* some of the arguments are evaluated twice.

--
pete

[Ian Collins]

Malcolm McLean wrote:

>>

Exactly. If you are doing very advanced programming then either you have
to be brillinat and encyclopedic, or you have to use code you don't
understand. Not an ideal situation, but it is very often necessary to do
that.

>>

You may not understand it, but you should cite the source and explain
why you trust it.

>>

They are function-like macros. Unfortunately some of the arguments are
evaluated twice - a sng with the C macro system. I find lower case more
tasteful than upper

x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

The upper case gives the macro an emphasis it shouldn't have.

The point of the emphasis is to make it clear that they are macros.
Conventions evolve for good reasons and upper case macros the the
closest a C convention comes to being a standard.

Cut and paste is generally a far superior method. Libraries are fine if
you are implemeting something fundamental like OpenGL, but not when you
need a list of dependencies in your code. No one wants to link in five
libraries all with conflicting definition of "bool" just to use a few
string functions.

What utter bollocks. Do you cut and past your system's code for printf
into every module of code that uses it? No, you use the library.

What do you do when you find a bug in your copy and paste (which from
Eric's report appears to be common)?

--
Ian Collins.

[Ben Bacarisse]

"Malcolm McLean" <re*******@btinternet.comwrites:

I am not wedded
to the idea that my choice on size_t is the right one.
However there are some thigns you fail to appreciate.

<snip>

Another thing you fail to appreciate is that compressed data is
inherently a binary format, and ought to be a portable binary
format. So the size integer has to be stored as a fixed number of
bytes, with fixed endianness. So a size_t, with size unknown, isn't an
appropriate type. It makes a promise that might not be fulfilled.

So your function declares the 'len' parameter as 'int' rather than
'size_t'. How is that better? The size of 'int' is as "unknown" as
the size of 'size_t'.

A function that compresses data held in a C object (as yours does)
can't reply on being told the size in an int. That is what size_t is
for. Furthermore, writing out the size in a portable format is just
as easy if 'len' is a size_t as it is if 'len' is an int (slightly
easier, in fact, since you don't have to worry about >on negative
values).

If
you are determined to pass in a size_t nevertheless there are of
course ways round this, like storing the number of bits before the
size,

No, just write out the data length in the format of your choice. It
is, as I say, no easier when the length is in an int.

--
Ben.

[Eric Sosman]

Malcolm McLean wrote:

>
"Eric Sosman" <Er*********@sun.comwrote in message
news:1186440511.431078@news1nwk...

>[...]
The book's implementation of mystrdup() compels a C99
compiler to emit diagnostics.

You repeat this several times. What you mean is that the function bodies
are given without headers. As you delve into deeper chapters

"Deeper." Good word, that. Suggests "down," and "lower,"
and "stuff rising over the tops of the waders." I'll pass,
thanks, and leave the journey to bolder spelunkers.

you will
soon see why this is - text interspersed with code means that the
headers make too much visual mess without adding enough information
content to justify inclusion.

How can you plead against "visual mess" when you cannot
even indent your code reasonably? How can you plead against
one or two #include lines in the face of those bloviated comments?
I don't buy it: I think the headers are missing because you are
careless, a sloppy worker.

The problem is that by saying "a C99 compiler is compelled to emit
diagnostics" rather than "I think it would have been better to include
headers and prototypes" you really disqualify yourself as an objective
commentator.

Diagnostics are also required from C89 compilers. There was
nothing to "require" such diagnostics from pre-Standard compilers,
but all those I used would have diagnosed at least two of your
functions. The fact that you didn't *know* the code was in error
for all C standards present and past and even for pre-Standard C
is a strong indication that you ought never to have written the book.
Ah, but that's the catch: You don't know, so you don't know you
don't know, don't you?

> At about this point, the text draws attention to some
coding conventions. Among them: the use of the identifier
`answer' to hold a function's return value. Oddly enough,
this mention is the last appearance of "answer" in the
chapter; the rest of the functions do not follow the
stated convention.

The convention applies for the whole book. "answer" isn't absolutely
uniform, but it is my normal choice for a variable to hold a return value.

A "normal choice" the chapter never uses again. But it's
a small point; you've shown more than once that you are no
respecter of convention, so it's no real surprise that you do
not even respect your own.

>There follows a peculiarity: A day-of-the-week function
that the author confesses he does not understand. The code
was "lifted from the net," says the book, but does not say
whether it was lifted from a reliable or from an unreliable
source. The text says it's all right to use a function you
don't understand, provided you "trust the author" -- but
since the author is unnamed, we do not have the means to
tell whether he is trustworthy.

Exactly. If you are doing very advanced programming then either you have
to be brillinat and encyclopedic, or you have to use code you don't
understand. Not an ideal situation, but it is very often necessary to do
that.

"Very advanced" programming??? Zeller's Congruence is the
sort of thing kids do in their first few weeks of BASIC. It's
often found in beginners' programming texts as a simple exercise
in integer division and modulus.

But: Why should we "trust the author" of this code "lifted
from the net" without attribution? There's lots and lots and
lots of code on the net, along with unmaskings of the faked Lunar
landings, squarings of the circle, proofs that the Universe is
only six thousand years old, and intriguing offers from Nigeria.
Why should we "trust the (unidentified) author" of this snippet?
Why do *you* trust him or her? Did you test the code? Perhaps
you did -- about as rigorously as you tested readline() ...

When you use the Argument From Authority, it is essential
to identify the Authority.

>[...]
- Number of functions with bugs (beyond required
diagnostics) spotted by this reader: four

Need to check those bugs.

You do, indeed. Or rather, "you did" -- but you didn't.
I could be wrong, but I truly think you were (are) capable
of checking, and of understanding what's wrong, and of fixing
it -- but you just didn't bother. Don't you *care* about the
quality of that which bears your name?

Thanks for the input.

Would it had not been necessary!

I bear no special animus towards you, Malcolm. I find you
irritating, but I imagine you find me much the same. This vile
book of yours, though -- It seems an affront, a flesh-crawlingly
repugnant scam perpetrated on unsuspecting buyers. The notion
that someone might actually give you money for this disaster is
close to sickening. I do not usually find myself emotionally
stirred by the goings-on in c.l.c., but you've both stirred
me and shaken me.

I'll say this for you: You are a brave person. Lots of
other people have written putrid books, but you are the first
I've known to invite your punishment.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Richard]

"Malcolm McLean" <re*******@btinternet.comwrites:

They are function-like macros. Unfortunately some of the arguments are
evaluated twice - a sng with the C macro system. I find lower case
more tasteful than upper

x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

The upper case gives the macro an emphasis it shouldn't have.

I have to disagree with you there. And you have gone against years of
"standard" in the C world.

Macros are nearly always upper case in the legacy code systems I have
been involved in.

[Kelsey Bjarnason]

[snips]

On Mon, 06 Aug 2007 20:55:52 +0100, Malcolm McLean wrote:

However there are some thigns you fail to appreciate. For instnace I suggest
using negative sizes to indicate "data fialed to compress".

Marvellous. You also use them to specify magic values going *into* your
compression routines: int squiz(void *buff, int size) or some such.
Since this means that one can no longer use legitimately-sized buffers
safely with your code *and* your code obviously expects magic values, the
code is nowhere near as clear or as safe as you seem to think it is.

Another thing you fail to appreciate is that compressed data is
inherently a binary format, and ought to be a portable binary format. So
the size integer has to be stored as a fixed number of bytes, with fixed
endianness.

So?

So a size_t, with size unknown, isn't an appropriate type.

Good. How big's an int? Hmm... 16 bits here, 32 there, 64 somewhere
else... and 36 bits on at least one implementation, IIRC. Which of the
umpteen allowable and unknown-at-design-time sizes is the known size?

Oh, right, none of 'em. So much for that argument.

However you draw the conclusion that because you disagree with the
decision over size_t, there are weaknesses, which you lack the ability
to discover, within the rest of the work. That seems to me pure bluster.

Err... no, that's not what I said. I said that there is absolutely no
justification for using int instead of size_t in a size context - something
you have yet to support - and this is a very, very bad design decision;
given that you've made such a bad decision here, it's simply to be
expected you make other such decisions elsewhere. Can one, with effort,
discover them? Very likely.

Given the choice between doing so and choosing someone else's work, work
which doesn't make such errors up front and in your face, work which
actually gives the impression that the author cares enough to do things
safely and properly, which should one prefer?

You, apparently, prefer works where there are some concept failures
smacking you in the face telling you you can't rely on the author's
judgement. Me, I prefer works where the author instills a sense of trust
by doing things right. I'm funny that way.

Oh well. None of this is topical anyhow, we should prolly kill the thread.

[Kelsey Bjarnason]

[snips]

On Mon, 06 Aug 2007 18:48:30 -0400, Eric Sosman wrote:

The chapter closes with an argument that putting code
in libraries that can be shared by many programs is a Bad
Thing; the "right" way to re-use code is to paste a copy
wherever you happen to need one. (No, I am not making this
up!)

Oh good goat, I managed to miss that bit. 'Scuse me while I go and cry in
my coffee a bit.

[Kelsey Bjarnason]

[snips]

On Tue, 07 Aug 2007 00:17:02 +0100, Malcolm McLean wrote:

The non-conforming implementation is an example of the book's style. It is
not written in C that happens to conform to the standards of the day

Guess what? We use compilers, a language and other tools that _do_
conform to the standards of the day. If you want to code in something
else, how about Pascal or BASIC?

>or from an unreliable source. The text says it's all right to use a
function you don't understand, provided you "trust the author" -- but
since the author is unnamed, we do not have the means to tell whether
he is trustworthy.

Exactly. If you are doing very advanced programming then either you have
to be brillinat and encyclopedic, or you have to use code you don't
understand. Not an ideal situation, but it is very often necessary to do
that.

Sure - yet we have absolutely no reason to trust the code, as we have no
clue where it came from.

x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

Perhaps, but it lends itself to thinking of clamp as a function, not a
macro. Unless great care is taken with such macros to avoid issues such
as multiple evaluation, the results may not be what they would be if it
actually _were_ a function; CLAMP draws the attention that no, it is not
a function, it is a macro, so beware.

The upper case gives the macro an emphasis it shouldn't have.

It damn well *should* have it, as it is *not* a function, and given the
rest of the abysmally bad decisions taken in writing the code, I, for one,
have very little faith that macros are implemented safely in the book...
they *should* stand out, with big red flashing lights, shouting "Danger,
Will Robinson!"

Cut and paste is generally a far superior method. Libraries are fine if
you are implemeting something fundamental like OpenGL, but not when you
need a list of dependencies in your code. No one wants to link in five
libraries all with conflicting definition of "bool" just to use a few
string functions.

Why would you get _any_ definitions of bool in a _string_ library? Weird...

[Old Wolf]

On Aug 7, 11:17 am, "Malcolm McLean" <[e-mail]:

The non-conforming implementation is an example of the book's style. It is
not written in C that happens to conform to the standards of the day, but in
C which I expect to still compile and work in a hundred years' time.

A true visionary. We could do with more of those!

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:

On Tue, 7 Aug 2007 09:59:40 -0700, in comp.lang.c , Kelsey Bjarnason
<kb********@gmail.comwrote:

>>[snips]
On Tue, 07 Aug 2007 00:17:02 +0100, Malcolm McLean wrote:

[...]

>>x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

Perhaps, but it lends itself to thinking of clamp as a function, not a
macro.

sorta like assert() or atoi() you mean?

The point to note here is that the Standard itself follows the style
being objected to.

atoi() is defined by the standard as a function, not as a macro. Like
all standard functions, it may also be defined as a function-like
macro. But the macro implementation must be well-behaved, i.e., it
must evaluate each of its arguments exactly once.

assert() is one of the rare function-like things in the standard
library that's explicitly defined as a macro, but I would expect it to
be well-behaved also (though I'm a little surprised to see that the
standard doesn't require this). And there's a long-standing precedent
for assert(); I might have preferred ASSERT(), but the committee's job
was largely to codify existing practice.

I haven't looked at Malcolm's 'clamp' macro, but I understand that it
does evaluate some of its arguments more than once. It's for exactly
that reason that it should be named 'CLAMP' rather than 'clamp'.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Malcolm McLean]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

Mark McIntyre <ma**********@spamcop.netwrites:

>On Tue, 07 Aug 2007 16:26:52 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>>>I haven't looked at Malcolm's 'clamp' macro, but I understand that it
does evaluate some of its arguments more than once. It's for exactly
that reason that it should be named 'CLAMP' rather than 'clamp'.

If it evaluates its arguments more than once, it probably shouldn't be
a macro at all.

Perhaps so, but since it is a macro, its name should be 'CLAMP' rather
than 'clamp'. Perhaps there's an efficiency concern, and Malcolm
didn't want to assume the availability of inline functions.

Efficiency is one issue. Operations like clamping are so simple and so
common that function overhead can be a real concern.
The other problem is that C has no way of taking a generic scalar. Since
data of all types except maybe char can be clamped, there is no obvious type
for it to take as a function. With 14 separate integer types and still
counting, plus three real formats, the num ber of variants you would need is
too large.

As for lower case, that is partly aesthetics, partly saying "this is really
just another function". Of course the design of the macro processor means
that x = clamp(*ptr++, 0, 10); will compile but not work, which is a real
nuisance, but then I discourage over-terseness anyway. However the macro is
not written to be called as
clamp(x, 0, 10);
with a side-effect, even though most of the time you want to assign to the
variable you are clamping.
I also use uniform() and coin(), which have decorative parentheses purely to
make them look like functions. Except that arguably it makes it easier to
replace them with real functions if required. uniform() - generating a
random number on 0-1 - in particular you might want to rewrite with a call
to a better randomiser.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Eric Sosman]

Mark McIntyre wrote On 08/08/07 17:10,:

On Tue, 07 Aug 2007 16:26:52 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>>Mark McIntyre <ma**********@spamcop.netwrites:

>>>The point to note here is that the Standard itself follows the style
being objected to.

atoi() is defined by the standard as a function, not as a macro.

The comment is irrelevant to my point - which was that the Standard
follows the same 'standard' as Malcolm for function-like macros,

Since atoi() is a function and not a macro, what has
its name got to do with the naming of function-like macros?

and
raising that as a serious objection to his code was IMHO overly
pedantic.

When I raised the point, I said the macro names were
legal but "in poor taste." Call me pedant if you like, but
please don't do so on account of things I didn't write.

If it evaluates its arguments more than once, it probably shouldn't be
a macro at all.

Right. But they *are* macros, and that's my reason
for calling them "bad."

--
Er*********@sun.com

[Flash Gordon]

Malcolm McLean wrote, On 08/08/07 23:01:

>
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>Mark McIntyre <ma**********@spamcop.netwrites:

>>On Tue, 07 Aug 2007 16:26:52 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
I haven't looked at Malcolm's 'clamp' macro, but I understand that it
does evaluate some of its arguments more than once. It's for exactly
that reason that it should be named 'CLAMP' rather than 'clamp'.

If it evaluates its arguments more than once, it probably shouldn't be
a macro at all.

Perhaps so, but since it is a macro, its name should be 'CLAMP' rather
than 'clamp'. Perhaps there's an efficiency concern, and Malcolm
didn't want to assume the availability of inline functions.

Efficiency is one issue. Operations like clamping are so simple and so
common that function overhead can be a real concern.

I thought your book was an algorithms book not a micro-optimisation book?

The other problem is that C has no way of taking a generic scalar. Since
data of all types except maybe char can be clamped, there is no obvious
type for it to take as a function. With 14 separate integer types and
still counting, plus three real formats, the num ber of variants you
would need is too large.

That is a potentially valid reason.

As for lower case, that is partly aesthetics,

Not, in my opinion, a good reason for going against long established
conventions.

partly saying "this is
really just another function".

Ah, but it is not!

Of course the design of the macro
processor means that x = clamp(*ptr++, 0, 10); will compile but not
work, which is a real nuisance,

Which is why you should make it clear by using upper case as is
conventionally done.

but then I discourage over-terseness
anyway.

I thought you were writing this stuff for other people? Remember that
others might not share your opinion of how terse things should be.

However the macro is not written to be called as
clamp(x, 0, 10);
with a side-effect,

Which is why it should be made crystal clear, anf the conventional
method for this is to use upper case.

even though most of the time you want to assign to
the variable you are clamping.
I also use uniform() and coin(), which have decorative parentheses
purely to make them look like functions. Except that arguably it makes
it easier to replace them with real functions if required. uniform() -
generating a random number on 0-1 - in particular you might want to
rewrite with a call to a better randomiser.

Personally I would say that in a book about algorithms using functions
is better than using macros as you then don't have to deal with
irrelevancies to your core material like pointing out the need to avoid
side effects.

I would not reject your book for using lower case names for macros,
although in my opinion it is a valid criticism. A lot of the other
criticisms are far better reasons for rejecting it.
--
Flash Gordon

[Richard Heathfield]

Flash Gordon said:

<snip>

I would not reject your book for using lower case names for macros,
although in my opinion it is a valid criticism.

It depends on the situation. The case in point cries out for upper case
as a "here be dragons" warning, but there are situations where a lower
case or mixed case macro works well.

For example, I use mixed-case function-like macros with names of the
form prefix_MacroName to enable me to conditionally wrap allocation
functions - if foo is defined, the wrappers are called (with __FILE__
and __LINE__ information added at that point); otherwise, malloc & co.
are called directly. These macros don't evaluate their arguments more
than once, and their name format is in keeping with true functions
belonging to the same library, so that the homogeneity of the code is
preserved. It works very well.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Kelsey Bjarnason]

[snips]

On Tue, 07 Aug 2007 23:26:14 +0100, Mark McIntyre wrote:

>>Guess what? We use compilers, a language and other tools that _do_
conform to the standards of the day.

You do ? Where did you find a portable fully C99 compliant toolset?

As far as C usage is concerned, the standard of the day is C89. ISO may
think otherwise, but while ISO defines standards for language versions,
developers determine which versions - or alternatives - to use, and by and
large have decided to stick with C89.

>If you want to code in something
else, how about Pascal or BASIC?

Newsflash: C89 is still C.

Newsflash: nobody but you seems to be confused about that.

>>Perhaps, but it lends itself to thinking of clamp as a function, not a
macro.

sorta like assert() or atoi() you mean?

The point to note here is that the Standard itself follows the style
being objected to.

Yes, and the standard also includes gets. What's your point? We should
use gets, because it's standard? Sounds good to me - let me know when
your production code makes extensive use of it.

[Malcolm McLean]

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:0u************@spanky.localhost.net...

>
Yes, and the standard also includes gets. What's your point? We should
use gets, because it's standard? Sounds good to me - let me know when
your production code makes extensive use of it.

There are a few glitches in the standard.
Another one is the banning of pasing a char to the isxxx() character
classifiers, on the grounds that it might be signed and break a lookup
table.

I ignored that little problem as well.

Another problem is the use of size_t. I am sure the committee thought they
were patching up a tiny little difficulty with malloc(). In fact they
created a monster which runs through the the whole code base of anyone
foolish enough to admit even one size_t into their interface.

However lowercase for function and function-like macros isn't really a
defect, except for the multiple evaluation problem. It is a real issue, no
point pretending it is not. The question is whether it really justifies the
visual clutter of capitalisation.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Al Balmer]

On Thu, 9 Aug 2007 21:43:10 +0100, "Malcolm McLean"
<re*******@btinternet.comwrote:

>However lowercase for function and function-like macros isn't really a
defect, except for the multiple evaluation problem. It is a real issue, no
point pretending it is not. The question is whether it really justifies the
visual clutter of capitalisation.

In my opinion, actual or potential "real issues" always outweigh
"visual clutter."

--
Al Balmer
Sun City, AZ

[Eric Sosman]

Malcolm McLean wrote On 08/09/07 16:43,:

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:0u************@spanky.localhost.net...

>>Yes, and the standard also includes gets. What's your point? We should
use gets, because it's standard? Sounds good to me - let me know when
your production code makes extensive use of it.

There are a few glitches in the standard.
Another one is the banning of pasing a char to the isxxx() character
classifiers, on the grounds that it might be signed and break a lookup
table.

I ignored that little problem as well.

Good! At a stroke, you've cured three of the bugs
I spotted in your first chapter -- not by fixing them,
but by blaming them on the Standard. Bravo! Your book
gets better and better with each new finger-pointing!

Any other aesthetically unpleasant facts you'd like
to gloss over? "In a better-designed world this mushroom
would be safe to eat, so I'll just ignore the little
problem that it might not be."

--
Er*********@sun.com

[Kelsey Bjarnason]

[snips]

On Thu, 09 Aug 2007 00:04:51 +0000, Richard Heathfield wrote:

Flash Gordon said:

<snip>

>I would not reject your book for using lower case names for macros,
although in my opinion it is a valid criticism.

It depends on the situation. The case in point cries out for upper case
as a "here be dragons" warning, but there are situations where a lower
case or mixed case macro works well.

Yes - when written by someone who actually shows something of an
understanding of the issues involved, a skill at avoiding them, and
having an actual reason for doing so.

Or, in other words, I'd tend to trust that even "hidden" macros written
by you prolly work; I'd be less inclined to believe that in the case of
Malcolm.

[Mark McIntyre]

On Wed, 08 Aug 2007 18:11:01 -0400, in comp.lang.c , Eric Sosman
<Er*********@sun.comwrote:

Since atoi() is a function and not a macro, what has
its name got to do with the naming of function-like macros?

*whoosh*.

When I raised the point, I said the macro names were
legal but "in poor taste." Call me pedant if you like, but
please don't do so on account of things I didn't write.

Hm. From where I'm sitting, you seemed to be raising this as a serious
objection to his code.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Wed, 8 Aug 2007 17:15:28 -0700, in comp.lang.c , Kelsey Bjarnason
<kb********@gmail.comwrote:

>[snips]

On Tue, 07 Aug 2007 23:26:14 +0100, Mark McIntyre wrote:

>>>Guess what? We use compilers, a language and other tools that _do_
conform to the standards of the day.

You do ? Where did you find a portable fully C99 compliant toolset?

As far as C usage is concerned, the standard of the day is C89.

My point exactly.

>>
Newsflash: C89 is still C.

Newsflash: nobody but you seems to be confused about that.

Okay, I'm baffled. You seem to be arguing against yourself now. Did
you do a reality check recently?

>The point to note here is that the Standard itself follows the style
being objected to.

Yes, and the standard also includes gets. What's your point?

Lost on you apparently.

>We should
use gets, because it's standard? Sounds good to me - let me know when
your production code makes extensive use of it.

Hilarious.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:

On Wed, 08 Aug 2007 14:40:44 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>>The comment is entirely relevant to your point.

Whatever. You *know* what I was saying, your pointless pedantry
notwithstanding.

[...]

No, I honestly don't know what you're trying to say. If you think I'm
engaging in "pointless pedantry", then I can only assume that you
don't know what I'm trying to say.

I had written a fairly lengthy point-by-point response to what you
wrote, but I've decided not to bore everyone with it. Briefly: you
have misunderstood and/or misrepresented what I wrote. I have not
deliberately misrepresented what you wrote; if I did so
unintentionally, it's because I can't figure out what point you're
making.

There is a convention (not a firm requirement, but an important
stylistic guideline) for macro names to be in all-caps. The purpose
of this is to call attention to the fact that something is a macro
rather than a function. This is particularly important for a
function-like macro that evaluates an argument more than once, as a
function cannot do. (I know you know this. I'm establishing context,
not trying to be condescending.)

In Malcolm's book, he presents a macro called 'clamp' that evaluates
one if its arguments more than once. (I haven't directly confirmed
this, but Malcolm hasn't disputed it.) As a matter of style, this
macro *should* have been called 'CLAMP' rather than 'clamp'. There's
nothing illegal about calling it 'clamp'; it's just a poorly chosen
and misleading name.

When some of us pointed this out, you objected to our "pointless
pedantry". I'll agree that it's pedantry (there's nothing wrong with
pedantry), but not that it's pointless. I have no idea why you object
to this.

Feel free either to explain, or to drop this.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

Keith Thompson wrote:

[...]
In Malcolm's book, he presents a macro called 'clamp' that evaluates
one if its arguments more than once. (I haven't directly confirmed
this, but Malcolm hasn't disputed it.)

The macro has three arguments. Depending on their
respective values, they are evaluated

- once, twice, and never, or

- twice, once, and twice, or

- thrice, once, and once.

The other macro, `lerp', evaluates its three arguments
somewhat more predictably: twice, once, and once, regardless
of their values. No sequence point separates the evaluations
of the first argument.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Eric Sosman]

Mark McIntyre wrote:

On Wed, 08 Aug 2007 18:11:01 -0400, in comp.lang.c , Eric Sosman
<Er*********@sun.comwrote:

> Since atoi() is a function and not a macro, what has
its name got to do with the naming of function-like macros?

*whoosh*.

SPLATTTTT!

> When I raised the point, I said the macro names were
legal but "in poor taste." Call me pedant if you like, but
please don't do so on account of things I didn't write.

Hm. From where I'm sitting, you seemed to be raising this as a serious
objection to his code.

I raised it as an objection whose seriousness was a matter
for prospective users to judge, based on their own points of
view. I gave the side-effects problem more weight. Hence the
distinction between "poor taste" (for the identifiers) and "bad"
(for the expansions).

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:

On Thu, 09 Aug 2007 16:24:28 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

[...]

>If you think I'm engaging in "pointless pedantry", then I can only
assume that you don't know what I'm trying to say.

I *think* you're trying to say that the Standard can do this because
its the Standard, but Malcolm can't because he's Malcolm, and you've
thrown in a red herring about evaluating arguments twice for no reason
that I can discern.

[snip]

You've just confirmed that you don't understand what I'm trying to
say. Let's just assume it's because I'm not expressing myself clearly
and move on.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

Mark McIntyre wrote:

[...] It seemed to me that the
OP was attacking Malcolm gratuitously [...]

Um, er, the O.P. is Malcolm.

If you meant to say "S.P." then you might have
meant me. If so, I reject both tines of your forking
accusation: First, I attacked not Malcolm but Malcolm's
book, and second, there was nothing gratuitous about it.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Kelsey Bjarnason]

On Thu, 09 Aug 2007 21:43:10 +0100, Malcolm McLean wrote:

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:0u************@spanky.localhost.net...

>>
Yes, and the standard also includes gets. What's your point? We
should use gets, because it's standard? Sounds good to me - let me
know when your production code makes extensive use of it.

There are a few glitches in the standard.

Very likely, yet it (or rather, they - C89,C99) is what defines the
language we use, so while we can certainly avoid parts of it (gets and
atoi, for example), we are stuck with working withing the constraints of
it if we wish to develop good, useful code, except in those cases where
said code is inherently non-portable and relies on implementation-
specific things beyond the scope of the code.

The code you presented has no such requirement, so it adheres to - or
should adhere to - the standard. It would also be beneficial if it
adhered to the collective wisdom of those who have been using C
professionally for a long enough time to know what does and doesn't work.

Another one is the banning of
pasing a char to the isxxx() character classifiers, on the grounds that
it might be signed and break a lookup table.

Er... it might.

I ignored that little problem as well.

Ignored as in merrily passed in signed chars without any attempt to do
the right thing?

Another problem is the use of size_t.

It's only a problem for you; everyone else seems to manage to use it
easily enough.

I am sure the committee thought
they were patching up a tiny little difficulty with malloc().

More likely, with sizes in general.

In fact
they created a monster which runs through the the whole code base of
anyone foolish enough to admit even one size_t into their interface.

It is "foolish" to use the proper tools, the ones designed for the job to
be done, is it? And you wonder why collective wisdom seems to be that
your book is utter rubbish.

However lowercase for function and function-like macros isn't really a
defect, except for the multiple evaluation problem. It is a real issue,
no point pretending it is not. The question is whether it really
justifies the visual clutter of capitalisation.

Anything that says "Hey, I'm here and I'm potentially dangerous, for
completely unexpected reasons" is a good thing. strcpy could be
dangerous for _expected_ reasons; macros which masquerade as functions
are potentially dangerous for wholly _unexpected_ reasons - the developer
sees what looks like a function, uses it like it's a function, but it may
well behave very differently from a function; this is not good, and
worse, it hides the fact.

I take it you've never heard of the concept of defensive programming.

[Kelsey Bjarnason]

[snips]

On Sat, 11 Aug 2007 06:30:06 +0100, Malcolm McLean wrote:

The standard says that a char argument to isspace() is illegal.

Not quite; the isxxx functions require that the value passed be either
EOF or representable as an unsigned char; nothing prevents many char
values from having this property.

That's clearly quite unacceptable.

Yet the functions work and have been working since at least 1989, with
nobody else affronted enough by the functions for them to have been
changed - despite the endless debates by some rather bright people over
what should be in and what should be changed in the standards.

Perhaps they, unlike you, realize that a large part of the appeal of C it
its efficiency. I'm quite certain they _could_ change isxxx to accept
pretty much anything, but that would require the function to test its
parameters to ensure they're in the legal range, which means additional
overhead for every single invocation. If one wants to use said functions
on largish strings - say to find the fist space in a string - the
overhead may well be unacceptable, particularly if the caller knows,
already, that the data is in an acceptable format. If it's not, he can
always cast or convert it - or write his own functions to replace isxxx,
or even a wrapper function which does the translation before calling
isxxx.

The "problem" is readily solvable for anyone who doesn't like how isxxx
works, *without* requiring every other developer to have unwanted
overhead forced on them by a standard designed for no reason but to hold
the hands of those who need such things; there are already languages
which do that, if you need that sort of hand-holding, use one of them.

the committee is pushing it in that direction. In fact it is so unlikely
that the reader will use a system that does break on char arguments, and
because the standrad is so absurd, I thought it best simply to sweep the
matter under the carpet.

Yes, and an int has a known size, while a size_t doesn't. Let me guess:
a byte is 8 bits, too, right?

The problem with algorithms is that the subject
matter can be made quite dry,

It gets even drier when one is forced to focus on the vagaries of
horrible code, trying to figure out whether the algorithm implementation
is as bad as the code written.

[Malcolm McLean]

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:l7************@spanky.localhost.net...

Yes, and an int has a known size, while a size_t doesn't. Let me guess:
a byte is 8 bits, too, right?

Someone sees

void compress(void *data, size_t sz)

he will naturally assume that the reason for the size_t is to allow the
function to compress an buffer that can be held in memory.

if he sees

void compress(void *data, int len)

then that assumption isn't as strong - he will tend to assume that any
integer can be accepted, of course, but it is not implicity assumed that all
functions taking integers can accept any parameters.
In fact the function will fail if the integer is over four bytes, because it
stores the length as four bytes. This restriction is extremely easy to
remove, of course, but it is reference implementation to show how the
algorithm works, which is the point of the book. It is not meant to define a
data compression standard for cross-platform use.

Bytes are eight bits. That is standard use of the term when defining binary
data formats, which have nothing to do with the C language. Of course a byte
is also the smallest addressible unit of memory. The word is used in two
ways. That's not uncommon, and its something you simply have to deal with.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Eric Sosman]

Malcolm McLean wrote:

>
"Eric Sosman" <Er*********@sun.comwrote in message
news:1186694915.312161@news1nwk...

> Good! At a stroke, you've cured three of the bugs
I spotted in your first chapter -- not by fixing them,
but by blaming them on the Standard. Bravo! Your book
gets better and better with each new finger-pointing!

The standard says that a char argument to isspace() is illegal. That's
clearly quite unacceptable.

Then your book should explain that its algorithms are
expressed in an idealized C-like pseudocode, not in C.

So you actually found one bug, not five, in ten functions. That's still
a big help, and I am grateful.

You clearly haven't taken the time to think about what
I wrote. ("But the dog did nothing in the night!") Hint.

The only comments I don't accept
graciously are insults with zero technical content.

... or with unpleasant truths. As somebody wrote recently
in this very thread:

>A lot of people can't distinguish "I disagree" with "you
are incapable of understanding". Don't let it get to you.
-- Malcolm McLean

--
Eric Sosman
es*****@ieee-dot-org.invalid

[santosh]

Malcolm McLean wrote:

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:l7************@spanky.localhost.net...

>Yes, and an int has a known size, while a size_t doesn't. Let me guess:
a byte is 8 bits, too, right?

<snip incomprehensible stuff>

Bytes are eight bits.

An octet is eight bits. Bytes need not be so, though they commonly are.

That is standard use of the term when defining
binary data formats, which have nothing to do with the C language.

The standard word for eight bits together is "octet".

Of
course a byte is also the smallest addressible unit of memory.

Again unwarranted assumptions. Many computer systems have word addressable
address space. Some may have bit addressable ones.

The word is
used in two ways. That's not uncommon, and its something you simply have
to deal with.

Yes. One way is to state clearly the meaning *you* have ascribed to the term
at the start of your work. If the meaning deviates gratuitously from the
norm for that work's domain, for no compelling reason, that's one more
point against the reliability of the said work and it's author[s].

[Peter J. Holzer]

On 2007-08-11 08:08, Kelsey Bjarnason <kb********@gmail.comwrote:

On Sat, 11 Aug 2007 06:30:06 +0100, Malcolm McLean wrote:

>The standard says that a char argument to isspace() is illegal.

Not quite; the isxxx functions require that the value passed be either
EOF or representable as an unsigned char; nothing prevents many char
values from having this property.

>That's clearly quite unacceptable.

Yet the functions work and have been working since at least 1989, with
nobody else affronted enough by the functions for them to have been
changed -

I do remember the argument that "including EOF in the is* functions was
probably a mistake", but IIRC that mistake has been made before the
standard. The standard had little choice except follow existing practice
here.

I also remember the argument that on a system where the system character
set includes characters with the high bit set char should be unsigned.
However, the standard doesn't require this (at least not directly, and
there have been long debates whether an indirect requirement can be
constructed), and most compiler vendors disagreed anyway, so for
portable programs you always had to be prepared to deal with negative
char values.

Perhaps they, unlike you, realize that a large part of the appeal of C it
its efficiency. I'm quite certain they _could_ change isxxx to accept
pretty much anything, but that would require the function to test its
parameters to ensure they're in the legal range, which means additional
overhead for every single invocation.

More importantly, it would render almost all existing implementations
non-conforming, it might render a lot of existing code non-conforming,
and new code couldn't depend on it for a long time.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Kelsey Bjarnason]

[snips]

On Sun, 12 Aug 2007 12:48:10 +0200, Peter J. Holzer wrote:

I do remember the argument that "including EOF in the is* functions was
probably a mistake", but IIRC that mistake has been made before the
standard. The standard had little choice except follow existing practice
here.

There may well have been such a discussion - and there may well be
reasons for it. However, even with it, it need not impose onerous
overhead. His preferences imply forcing everyone to accept unwanted and
unnecessary overhead, rather than simply writing his own routines which
work the way he likes and using them.

More importantly, it would render almost all existing implementations
non-conforming, it might render a lot of existing code non-conforming,
and new code couldn't depend on it for a long time.

Yeah, well, that sort of thing doesn't seem to bother him much. size_t
is bad, and all, you know, despite the fact int, as he persists in using
it, simply _cannot_ do the same job.

[pete]

Eric Sosman wrote:

>
ms*******@yahoo.com wrote On 07/25/07 10:56,:

On Jul 24, 3:18 pm, "Malcolm McLean"
<[e-mail]:

>The webpages for my new book are now up and running.

It may be I've actually leaned something new
from the sample pages of the book. To quote:

Note that strlen() is a "pure function". It performs no input or
output, and all the information it requires is contained in the
parameters. One of the features of C is that there is no distinction
between a "function", which calculates something, and a "procedure",
which performs IO.

He says there's no distinction, tries to draw one,
and ends up spreading confusion.

Now I had always had in my mind (going back to the days of learning
BASIC in the '70s) that the difference between a function and
procedure is that a function returns a value
and a procedure doesn't.
But I could be wrong.

Different programming languages use different terms
to describe various flavors of functions, subroutines,
procedures, methods, lambda expressions, and so on. When
you're dealing with definitional niceties, you need to do
so in the context of a particular language; the next in
line may use the same word but with a different meaning.

In the specific case of C, "procedure" is a word with
no meaning. The Standard does not define it; the Standard
does not even use the word. So there's no way for C to
clear up any confusion you may have about the precise meaning
of "procedure;" one might just as well ask about the precise
meaning of "coroutine."

By the way, "pure function" is another phrase not defined
or used by the C Standard. The term is in general use, with
a meaning somewhat along the lines Malcolm mentions: most
people describe a function as "pure" if it has no "visible"
side-effects. Section 7.5 paragraph 3 of the C Standard
explicitly permits strlen() to have an externally-visible
side-effect, so strlen() need not be "pure" at all!

Here's a quote from chapter one:
One of the features of C is that there is no distinction
between a “function”, which calculates something,
and a “procedure”, which performs IO.
This doesn’t mean that the difference
is unimportant from a design perspective.

My opinion is that the difference between functions
and procedures *is* unimportant from a design perspective,
in languages like C, where there is no difference.

--
pete

[pete]

pete wrote:

>

Here's a quote from chapter one:
One of the features of C is that there is no distinction
between a “function”, which calculates something,
and a “procedure”, which performs IO.
This doesn’t mean that the difference
is unimportant from a design perspective.

My opinion is that the difference between functions
and procedures *is* unimportant from a design perspective,
in languages like C, where there is no difference.

And then it also says:
Separating the functions from the procedures
is usually the first step in a good design.

Does anybody ever actually do that when coding in C?
I've never given a thought to segregating functions
according to whether or not a function had side effects
or a return value.

--
pete

[Ian Collins]

pete wrote:

pete wrote:

>Here's a quote from chapter one:
One of the features of C is that there is no distinction
between a “function”, which calculates something,
and a “procedure”, which performs IO.
This doesn’t mean that the difference
is unimportant from a design perspective.

My opinion is that the difference between functions
and procedures *is* unimportant from a design perspective,
in languages like C, where there is no difference.

And then it also says:
Separating the functions from the procedures
is usually the first step in a good design.

Does anybody ever actually do that when coding in C?
I've never given a thought to segregating functions
according to whether or not a function had side effects
or a return value.

Considering there isn't a single mention of "procedure" in the standard,
doing so (separating the functions from the procedures) would be rather
difficult.

--
Ian Collins.

[Richard Bos]

Mark McIntyre <ma**********@spamcop.netwrote:

On Wed, 08 Aug 2007 14:40:44 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

The comment is entirely relevant to your point.

Whatever. You *know* what I was saying, your pointless pedantry
notwithstanding.

The permission to redefine standard functions as macros is a
special-case rule that in no way applies to Malcolm's 'clamp'

The above reads, to me, thusly: "its ok for ISO to break conventions,
we like ISO. However its not ok for some guy whose style we dislike
here in CLC to do the same thing".

There's one big difference, though, which I think we've all overlooked:

# Any invocation of a library function that is implemented as a macro
# shall expand to code that evaluates each of its arguments exactly
# once, fully protected by parentheses where necessary, so it is
# generally safe to use arbitrary expressions as arguments.

That's from 7.1.7 in C89; I believe the same text is in C99. Because of
this requirement, the need for Standard function macros to be especially
recognisable is a great deal less than that for other macros.
Malcolm's macros, in contrast, _do_ evaluate their argument(s) more than
once, making it essential that their users recognise immediately that
that is what they do. Therefore, for his macros, capitals _are_
necessary, more so even than for most macros which only _might_ break if
passed an argument with side-effects.

Richard

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Mark McIntyre <ma**********@spamcop.netwrote:

>On Wed, 08 Aug 2007 14:40:44 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>The comment is entirely relevant to your point.

Whatever. You *know* what I was saying, your pointless pedantry
notwithstanding.

>The permission to redefine standard functions as macros is a
special-case rule that in no way applies to Malcolm's 'clamp'

The above reads, to me, thusly: "its ok for ISO to break conventions,
we like ISO. However its not ok for some guy whose style we dislike
here in CLC to do the same thing".

There's one big difference, though, which I think we've all overlooked:

# Any invocation of a library function that is implemented as a macro
# shall expand to code that evaluates each of its arguments exactly
# once, fully protected by parentheses where necessary, so it is
# generally safe to use arbitrary expressions as arguments.

[...]

Not to re-open the argument, but I believe I addressed that point.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Very.Little.Gravitas.Indeed]

On Aug 2, 9:03 pm, "Malcolm McLean" <[e-mail]:

One problem with algorithm books is that they are written to the latest
fashion in languages. It might be Fortran, or C, or C++, or Java. I expect
my book to be still useful in a hundred years time.

Meglomania is hardly a good reason to decide to do this. You could
make a book which is relevant now or a book that is never relevant
because in 100 years they'll probably have they're own size_t of the
future, and so your book will still be irrelevant in 100 years. You
can always release new eidtions to deal with changes.

Don't let pride get in the way writing a good book or improving your
understanding. If you are asking for feedback but you aren't accepting
it, then there wasn't much point asking in the first place.

The first rule is to consider yourself fallible, when you have
accepted that you can take steps to compensate. If you never consider
you could be wrong, or you could do things better, you will always be
wrong and will never do things better.

If your C understanding is not rigorous enough to provide bullet proof
examples in C use a Pseudo code or get someone who's understanding is
rigorous to write them.

The feedback is clear the C examples provided are not felt to be
adequate enough.

There are plenty of mediocre computer books available, but the number
that are excellent is very few. Go that extra mile to create an
excellent book.

[Kelsey Bjarnason]

On Sun, 12 Aug 2007 23:44:12 -0400, pete wrote:

pete wrote:

>>

>Here's a quote from chapter one:
One of the features of C is that there is no distinction
between a “function”, which calculates something,
and a “procedure”, which performs IO.
This doesnÂ’t mean that the difference
is unimportant from a design perspective.

My opinion is that the difference between functions
and procedures *is* unimportant from a design perspective,
in languages like C, where there is no difference.

And then it also says:
Separating the functions from the procedures
is usually the first step in a good design.

Does anybody ever actually do that when coding in C?
I've never given a thought to segregating functions
according to whether or not a function had side effects
or a return value.

I tend to do them by task. Simple example, a windowing system (a la
curses) might have keyboard and mouse code, code to manage updating of the
"window" contents, code to manage the actual updating of the display, code
to manage multiple windows, etc, etc, etc.

Chances are, each of those would be in separate modules... but to split up,
oh, the code to update the contents of the display and the code that
calculates the boundaries of the region to update just because one does
output and the other is purely calculation seems a tad bizarre.

[Malcolm McLean]

"Malcolm McLean" <re*******@btinternet.comwrote in message
news:lo*********************@bt.com...
OK. The thread has died down.
Thank you to everyone who has participated. I do mean that sincerely. All
comments (except one person) are useful. It is bit depressing that no one
has said a single good thing about the book, but most of the really bad
things that could have been said haven't been.
Typos etc can easily be fixed. The capital macro issue is not really here or
there, and I think the ideal is to incorporate a discussion of the pros and
cons into the text. I know it is meant to be an algorithms book not a C
book.

size_t. Well pete's post in the How to implement a Hash Table in C thread
says it all. <87************@bsb.me.uk>. size_t can be confusing. I think I
am right here and the rest of the world is wrong.

The isxxx macros. The problem is that it makes the language look stupid if
you tell people that you can't pass a char to isspace(). One solution would
be to just put in a cast to unsigned and pass over it, but that's confusing.
Part of the idea of the book is to promote C as the natural laguage for
specifying algorithms.

I was going to look through the entire thread for errors. In fact Ben has
done this for me. Here's his list.
(1) redundant (i.e. provably true) if (ptr str) in strtrim
(2) array[y*10=x];
(3) if (8str == '}') in checkbalanced
(4) incorrect quotes on some char constants in the above function
(only visible in the book version)
(5) int expy;; in floating add (not an error, just an obvious typo).
(6) if(x & 0x7FFFFFFFF < y & 0x7FFFFFFF) in same (two errors here).
(7) if(tail == 100] in add (for a queue)
(8) no test for queue being full or queue being empty
(9) if(ptr == room->baddies) room->baddies = ptr; in removebaddy
(10) missing ";" after assert( x 0.0) squareroot
(11) null pointer dereference in fixedallocate
(12) The statement above about prime testing.

There's also the issue about the hash table not using quadratic probing, and
a serious typo about the car registration plate. The square root termination
condition is a bit more difficult, since logically flaoting point formats
ought to come before maths algorithms, but in fact I decided that the maths
functions would be a better lead in. I don't really want to get into epsilon
that early in the chapter. In practise a lot of quick and dirty
implementations do use a fixed number of Newton-Raphson iterations, however
it is a lousy square root, I will accept.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Heathfield]

Malcolm McLean said:

<snip>

I know it is meant to be an
algorithms book not a C book.

Then I suggest that you don't try to promote it in a C group. Otherwise,
it will be judged on its C merits.

size_t. Well pete's post in the How to implement a Hash Table in C
thread says it all. <87************@bsb.me.uk>. size_t can be
confusing. I think I am right here and the rest of the world is wrong.

"I was so proud of my son in the big parade today - do you know, he was
the *ONLY ONE* who was walking in step?"

The isxxx macros. The problem is that it makes the language look
stupid if you tell people that you can't pass a char to isspace(). One
solution would be to just put in a cast to unsigned and pass over it,
but that's confusing. Part of the idea of the book is to promote C as
the natural laguage for specifying algorithms.

I'm not sure that's true - but if it *is* true, then how can C look
stupid when used properly?

<snip>

The
square root termination condition is a bit more difficult,

Remind me why you need it? Is it for primality testing? If so, well, you
don't need to calculate any square roots. You can get away with
calculating a square instead - and that shouldn't be too hard.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[pete]

Malcolm McLean wrote:

size_t. Well pete's post in the How to implement
a Hash Table in C thread says it all. <87************@bsb.me.uk>.
size_t can be confusing. I think I
am right here and the rest of the world is wrong.

size_t can be confusing,
but when you're counting parts of objects,
then size_t is appropriate and not confusing.

size_t isn't totally wrong for counting allocated objects either.
size_t is usually pretty big
and using the largest unsigned type instead,
doesn't guarantee that any problem that would have resulted
from using size_t to count allocated objects,
could be avoided; especially if size_t
happens to also be the same as the largest unsigned type.
Also, using size_t, it's possible to write C89 code,
that compiles on a C99 implementation
where size_t is long long unsigned.

--
pete

[pete]

Richard Heathfield wrote:

The
square root termination condition is a bit more difficult,

Remind me why you need it?

For the square root algorithm part of the algorithm book.

--
pete

[Chris Dollin]

Malcolm McLean wrote:

Part of the idea of the book is to promote C as the natural
laguage for specifying algorithms.

It isn't.

No one language is "the" natural language for specifying [all?]
algorithms. Different languages lend themselves to different
algorithms on different topics -- that's part of the reason we
/have/ different languages. Proof-by-compilation-into that you
can rewrite all those algorithms into C doesn't necessarily
make C "the natural language" for the job.

Render unto C that which is C, sir, and likewise for the
rest of the humming flock.

--
Polyglot Hedgehog
Otherface: Jena RDF/Owl toolkit http://jena.sourceforge.net/

[pete]

Chris Dollin wrote:

>
Malcolm McLean wrote:

Part of the idea of the book is to promote C as the natural
laguage for specifying algorithms.

It isn't.

No one language is "the" natural language for specifying [all?]
algorithms. Different languages lend themselves to different
algorithms on different topics -- that's part of the reason we
/have/ different languages. Proof-by-compilation-into that you
can rewrite all those algorithms into C doesn't necessarily
make C "the natural language" for the job.

Render unto C that which is C, sir, and likewise for the
rest of the humming flock.

I think that most programmers can read a lot of C,
even if they don't write in C.

I think C syntax is similar to many other languages, like java.
The first mergesort function that I ever wrote in C,
was one that I translated from java,
having never attempted to read java before.
Maybe Malcolm's new book should be in java?

Changing the topic back to size_t;
One thing that I find irritating,
is comparison sorting algorithm examples written in C,
showing arrays of type int
being sorted by functions that use type int as indexes.

When everything is type int,
it's more difficult to distiguish data and data comparisons
from book keeping variables and operations.

I very much like the etype interface that I learned from
the programmer currently known as user923005.
Then everything is either etype, pointer to etype, or size_t.

--
pete

[Malcolm McLean]

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:uc************@news.flash-gordon.me.uk...

So why have you not fixed them in the electronic version?

That should happen within the next day or so.
Theoretically I ought to be able to edit the text, press a button, and have
a new version. The reality isn't as easy as that. It took a whole day to
upload the Word file last time, and I had to make about twelve attempts. I
don't expect quite that level of difficulty next time, since it is now
formatted, but I've still got to use a wordprocessor I don't have at home,
which means going in to work to edit it outside of normal hours.
Theoretically I am in charge of my own timetable, in actual fact I can't
justify messing about with books when people need my biochemistry code.

Anyway, thanks again to all who have contributed. All comments are
appreciated, really.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Heathfield]

Malcolm McLean said:

>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:uc************@news.flash-gordon.me.uk...

>So why have you not fixed them in the electronic version?

That should happen within the next day or so.
Theoretically I ought to be able to edit the text, press a button, and
have a new version.

Pretty much, yes.

The reality isn't as easy as that. It took a whole
day to upload the Word file last time, and I had to make about twelve
attempts.

If you choose the wrong tools, you should not be surprised if the job
takes longer than it ought.

I don't expect quite that level of difficulty next time,
since it is now formatted, but I've still got to use a wordprocessor I
don't have at home,

No, you don't.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999