Malcolm's new book

[Kelsey Bjarnason]

Ben Bacarisse said:

int remove(int *item)
{
if (empty())
return 0;
*item = queue[head];
if (++head == Q_SIZE)
head = 0;
return 1;
}

is so complicated it obscures the basic idea. I think your example
will just baffle the learner.

It will baffle him even more if he includes <stdio.h> in his program.
The remove() function is a standard C library function.

<snip>

Why would that "baffle" anyone?

gcc test.c
test.c:7: error: conflicting types for ‘remove’
/usr/include/stdio.h:152: error: previous declaration of ‘remove’ was here

Clear enough?

 

[Malcolm McLean]

[snips]

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.

True but irrelevant. The book doesn't contain the occasional error; it
contains consistent, repeated failures to grasp basic concepts, then uses
those failures to build code.

The most obvious examples are using int where size_t (or, at the *very*
least, unsigned) would be proper, and assuming ints have 32 or more bits.

That was a writing decision.
unsigned integers have certain problems that can make algorithms with them
more difficult. For that reason they were excluded from Java. There is of
course some dispute about this, because ANSI mandates a size_t to hold
amounts of memory.
The other problem is that once you admit one size_t it poisons everything it
touches. So I decided not to use size_t at all, except once in the
introduction.

 

[pete]

The other problem is that once you admit one size_t
it poisons everything it touches.

size_t isn't hard to use.

It really seems like a failure to grasp a basic concept,
then using that failure to build code.

 

[Richard Heathfield]

Malcolm McLean said:

[snips]

The book doesn't contain the occasional error;
it contains consistent, repeated failures to grasp basic concepts,
then uses those failures to build code.

The most obvious examples are using int where size_t (or, at the
*very* least, unsigned) would be proper, and assuming ints have 32 or
more bits.

That was a writing decision.

Then it was a poor one.

unsigned integers have certain problems that can make algorithms with
them more difficult.

So do signed integers - for example, their behaviour on overflow. So if
you can't use signed and you can't use unsigned, what does that leave?

For that reason they were excluded from Java.

I have no comment on Java. They were not excluded from C.

There is of course some dispute about this, because ANSI mandates a
size_t to hold amounts of memory.

The only dispute is in your head. I've never heard anyone else, ever,
arguing that unsigned integer types are a bad thing.

The other problem is that once you admit one size_t it poisons
everything it touches.

No, the trick is to know when to use them and why to use them. Use the
right type for everything, and it all tends to come out in the wash.

For example, consider graphics. A frame buffer has a non-negative number
of rows (each representing a row of pixels) and a non-negative number
of columns (each representing a column of pixels). Since offsets into a
frame buffer represent row and column counts, it makes sense to use an
unsigned type.

On the other hand, sometimes you want to construct a world in which
negative co-ordinates make sense (e.g. a graph of tan theta). Since the
world needs negative co-ordinates, you need a signed type.

The frame buffer need *not* pollute the world, nor the world the frame
buffer. One simply determines that they represent different concepts,
and one then provides a mapping between them that doesn't violate the
integrity of either. Rendering a world view within the frame buffer
must involve mapping those negative values to non-negative values at
some point, so there is no real problem here at all. It's perfectly
okay to assign an int value to a size_t, you know.

So I decided not to use size_t at all, except once in the
introduction.

That decision was a mistake.

 

[Malcolm McLean]

Malcolm McLean said:

[snips]

The book doesn't contain the occasional error;
it contains consistent, repeated failures to grasp basic concepts,
then uses those failures to build code.

The most obvious examples are using int where size_t (or, at the
*very* least, unsigned) would be proper, and assuming ints have 32 or
more bits.

That was a writing decision.

Then it was a poor one.

unsigned integers have certain problems that can make algorithms with
them more difficult.

So do signed integers - for example, their behaviour on overflow. So if
you can't use signed and you can't use unsigned, what does that leave?

For that reason they were excluded from Java.

I have no comment on Java. They were not excluded from C.

There is of course some dispute about this, because ANSI mandates a
size_t to hold amounts of memory.

The only dispute is in your head. I've never heard anyone else, ever,
arguing that unsigned integer types are a bad thing.

They were excluded from Java.

Gosling: For me as a language designer, which I don't really count myself as
these days, what "simple" really ended up meaning was could I expect J.
Random Developer to hold the spec in his head. That definition says that,
for instance, Java isn't -- and in fact a lot of these languages end up with
a lot of corner cases, things that nobody really understands. Quiz any C
developer about unsigned, and pretty soon you discover that almost no C
developers actually understand what goes on with unsigned, what unsigned
arithmetic is. Things like that made C complex. The language part of Java
is, I think, pretty simple. The libraries you have to look up.

(Gosling was the designer of Java).
http://www.gotw.ca/publications/c_family_interview.htm

(I am not saying I absolutely agree with him. It's just a complexity we can
usually do without. Very rarely do you need that exta bit.)

 

[Richard]

Malcolm McLean said:



The only dispute is in your head. I've never heard anyone else, ever,
arguing that unsigned integer types are a bad thing.

I would say at at least 90% of the time I use "ints" is using unsigned
ones. Especially when one takes into account Malcolm's previous claims
that ints are usually used to access memory - not much call for signed
offsets there. So, agreed.

 

[Richard Heathfield]

Malcolm McLean said:

They were excluded from Java.

I have no comment on Java. Okay, fair play, you've found someone else
who doesn't like unsigned integer types (and a serious player, too, not
an illiterate non-entity from J Random Web Forum). Nevertheless, he's a
Java player, and we're discussing C here. In C, unsigned types remain
useful and powerful.

(I am not saying I absolutely agree with him. It's just a complexity
we can usually do without. Very rarely do you need that exta bit.)

If you mean 'bit' literally, that isn't why I use unsigned types (on
those occasions when I do use them) - it's not because of their greater
range, but because of their behaviour.

 

[santosh]

Malcolm McLean said:

[snips]

The book doesn't contain the occasional error;
it contains consistent, repeated failures to grasp basic concepts,
then uses those failures to build code.

The most obvious examples are using int where size_t (or, at the
*very* least, unsigned) would be proper, and assuming ints have 32 or
more bits.

That was a writing decision.

Then it was a poor one.

unsigned integers have certain problems that can make algorithms with
them more difficult.

So do signed integers - for example, their behaviour on overflow. So if
you can't use signed and you can't use unsigned, what does that leave?

For that reason they were excluded from Java.

I have no comment on Java. They were not excluded from C.

There is of course some dispute about this, because ANSI mandates a
size_t to hold amounts of memory.

The only dispute is in your head. I've never heard anyone else, ever,
arguing that unsigned integer types are a bad thing.

They were excluded from Java.

(I am not saying I absolutely agree with him. It's just a complexity we
can usually do without. Very rarely do you need that exta bit.)

I sometimes find the modulo 2^n arithmetic of unsigned integers useful. In
many programming areas, you only need to consider positive values and zero.
In such cases using a signed type is not optimal.

 

[Malcolm McLean]

Malcolm McLean said:


I have no comment on Java. Okay, fair play, you've found someone else
who doesn't like unsigned integer types (and a serious player, too, not
an illiterate non-entity from J Random Web Forum). Nevertheless, he's a
Java player, and we're discussing C here. In C, unsigned types remain
useful and powerful.


If you mean 'bit' literally, that isn't why I use unsigned types (on
those occasions when I do use them) - it's not because of their greater
range, but because of their behaviour.

The other argument is that if an integer is naturally unsigned, like the
number of employees in a company, unsigned documents that.
However I like to use -1 to mean "illegal".
int getNemployees(COMPANY *complexstruct)

int N = getNemployees(company)
if(N < 0)
{
/* for some reason it is a an error to try to get the number of
employees of this company - maybe it's a partnership and our rules don't
apply, or similar */
}

 

[Eric Sosman]

[...]
The other problem is that once you admit one size_t it poisons
everything it touches. [...]

Aw, fer cryin' out loud-- It's been only a week or so
since we had our latest extended and unpleasant ride on this
hobby horse of yours; can't you give us a respite of at least
a month between rockings? Let the "decent interval" elapse,
I beg.

Sheesh!

 

[Malcolm McLean]

[...]
The other problem is that once you admit one size_t it poisons everything
it touches. [...]

Aw, fer cryin' out loud-- It's been only a week or so
since we had our latest extended and unpleasant ride on this
hobby horse of yours; can't you give us a respite of at least
a month between rockings? Let the "decent interval" elapse,
I beg.

Sheesh!

The problem is that I have to write the code with either ints or size_t's.
Being an int should fit all man, I chose int.
This then leads to accusations of not having grasped the concept of size_t.
Of course it is pretty unlikely that someone would churn out 600 pages of C
code but lack the intellectual capacity to understand that size_t is the
ANSI recommended way of representing amounts of memory. I even discuss the
issue briefly in chapter 1. But I have to explain my reasons, whether you
accept them or not, rather than be thought ignorant of the existence of such
a type.

 

[Keith Thompson]

Malcolm McLean said: [...]

unsigned integers have certain problems that can make algorithms with
them more difficult.

So do signed integers - for example, their behaviour on overflow. So if
you can't use signed and you can't use unsigned, what does that leave?

For that reason they were excluded from Java.

I have no comment on Java. They were not excluded from C.

There is of course some dispute about this, because ANSI mandates a
size_t to hold amounts of memory.

The only dispute is in your head. I've never heard anyone else, ever,
arguing that unsigned integer types are a bad thing.

They were excluded from Java.

[...]

So maybe you should write a book about Java.

 

[Richard Heathfield]

Malcolm McLean said:

The problem is that I have to write the code with either ints or
size_t's. Being an int should fit all man, I chose int.

Why not just use the right type for the right use? The int type clearly
does not fit all. You use chars and doubles and arrays and structs
where appropriate, yes? Well then, why not unsigned integer types when
appropriate too?

This then leads to accusations of not having grasped the concept of
size_t.

Alas, such accusations do seem to be justified. You don't seem to have
grasped the idea at all.

Of course it is pretty unlikely that someone would churn out
600 pages of C code but lack the intellectual capacity to understand
that size_t is the ANSI recommended way of representing amounts of
memory.

Schildt didn't have any trouble turning out large amounts of material,
ostensibly about C, without actually understanding the language.

 

[Eric Sosman]

[...] Of course it is pretty unlikely that someone would churn out 600
pages of C code but lack the intellectual capacity to understand that
size_t is the ANSI recommended way of representing amounts of memory.

The few pages I read did not encourage me to read the rest
of the six hundred. Nor did they demonstrate overpowering
intellectual capacity; rather, they demonstrated slipshod
workmanship.

Seriously: If the code in your book (such of it as I had
stomach for) had been turned in by a student, I would have
given failing marks for the second square root function: code
that doesn't compile doesn't get good grades. Fix the two
obvious errors and it would still get a failing mark for not
implementing the specification (the one in the text immediately
following the code). Fix that third error, and it would get a
low pass: it works, but there are too many magic numbers and too
little thought.

When this shoddy code comes from a supposedly professional
programmer -- well, what am I to suppose? It seems unlikely that
you are actually so deluded that you thought the code was good,
so my guess is that you just didn't think about it at all. An
intellectual capacity that is not used just as effective as
none at all.

"Let us be thankful that we are persons of no capacity
whatever." -- Lord Tolloller

 

[¬a\\/b]

[...]
The other problem is that once you admit one size_t it poisons
everything it touches. [...]

it is possible i wrong anhother time but there is something not return
me well in size_t (the same for const etc etc )
possibly because i'm not very smart and not understand well

Aw, fer cryin' out loud-- It's been only a week or so
since we had our latest extended and unpleasant ride on this
hobby horse of yours; can't you give us a respite of at least
a month between rockings? Let the "decent interval" elapse,
I beg.

Sheesh!

and so if you code overflow a size_t variable your programme what has
to do?

is there something that can catch this? (and so **slow down** all the
executable from a c source too)

i think it is better "int" than "size_t" because i can see if it is ok
in the begin of some function and write something like

char* malloc(int a)
{if(a<0) return 0;
etc
}

yes i know the standard say "size_t" and if another type it will break
all existing c code but this is summer time and i have to say
something

 

[Ivar Rosquist]

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.

Methinks the low price is because this is a book that fills a
well-needed gap.

 

[Kelsey Bjarnason]

[snips]

The other argument is that if an integer is naturally unsigned, like the
number of employees in a company, unsigned documents that.
However I like to use -1 to mean "illegal".

As in "please compress this illegally-sized buffer" - the size parameter to
at least one of your compression functions is an int.

Nope, makes no sense at all. Nor does the "simple to remember" bit.
Quick - what happens on signed int overflow? Signed-int underflow?
Contrast those to what happens with unsigned in the same situation...

 

[Keith Thompson]

The other argument is that if an integer is naturally unsigned, like
the number of employees in a company, unsigned documents that.
However I like to use -1 to mean "illegal".
int getNemployees(COMPANY *complexstruct)

int N = getNemployees(company)
if(N < 0)
{
/* for some reason it is a an error to try to get the number of
employees of this company - maybe it's a partnership and our rules
don't apply, or similar */
}

Don't use magic numbers.

#define INVALID_NUMBER ((unsigned)-1)
unsigned getNemployees(COMPANY *complexstruct)
{
int N = getNemployees(company);
if (n == INVALID_NUMBER) {
/* ... */
}
}

 

[Keith Thompson]

Don't use magic numbers.

#define INVALID_NUMBER ((unsigned)-1)
unsigned getNemployees(COMPANY *complexstruct)
{
int N = getNemployees(company);

Sorry, that should be 'unsigned N = ...;'.

 

[Harald van =?UTF-8?B?RMSzaw==?=]

Sorry, that should be 'unsigned N = ...;'.

And that should be 'if (N == ...) {'

More to the point, I don't think I agree with your use of a positive value
to indicate an error in a function returning the number of employees. How
do you distinguish a company with UINT_MAX employees, from one of which the
number you cannot represent? If getNemployees returns an int, then it is
clear: either the number is negative, which is an obvious error result, or
it is non-negative, which signifies exactly the number of employees. It is
true that UINT_MAX employees also cannot be represented if the function
returns int, but at least in that case, the function unambiguously tells
you so.

Alternatively, I wouldn't necessarily object if getNemployees returned
unsigned long, and -1UL signifies an error, because it's not possible for a
company to have 0xFFFFFFFF or more employees.