Re: Malcolm's new book


"Kelsey Bjarnason" <kbjarnason@xxxxxxxxx> wrote in message news:qrb9o4-jj2.ln1@xxxxxxxxxxxxxxxxxxxxxxx
[snips]

On Sun, 29 Jul 2007 22:36:39 +0100, Malcolm McLean wrote:

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.

Bad choice.

int get_buff_len( buffer_t buff )

Quick: what happens if the length of the buffer is > INT_MAX? Hmm...
could be held in a size_t, which can handle the size of the largest
allowable object, but pukes on int.

Yeah, well. int.

In a 32-bit environment that is most unlikely. In a 64-bit environment, well, that's a different story.

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

Obviously, you haven't.

There is a difference between not understanding and disagreeing.

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.

Yet you get it wrong consistently.

I explain in the opening paragraphs why size_ts will not pollute my C code. You don't disagree with this reasoning, you either haven't read it or fail to engage with it.
(Needless to say I wouldn't say it is beyond dispute. Some pretty intelligent people disgree with me.)
I
even discuss the issue briefly in chapter 1.

Then you should know better.

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.

If you know it, you should use it. Since there is *no* possible
justification for using int in such cases, as sizes are never negative and
can overflow the range of an int, you simply cannot use int reliably in
such cases - which is *exactly* why size_t exists in the first place.

Intermediate size or index calculations can easily be negative.

Since you don't use size_t, one must conclude you're unaware of what it
is, what it's for and why it exists. If you *did* know, you'd have used
it, instead of int.

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. I'll be dead by then, but the fundamental algorithms that make computers work won't have changed. However languages change. I can't imagine C without int, but size_t could well be obsolete by then. I can't see a language that insists on a type called "size_t" as a general-purpose index lasting for long. Programmers simply won't accept it. But I don't think it will take down C.
People do disagree on what should go in textbooks.

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

.

Relevant Pages

  • Re: The Advantage of Macros
    ... which is usually a single source file, can consist of external declarations ... void fx(int *x, int *y) { ... Also, if you think C is complicated, just take a look at languages like C++, ... C pushes to wrong programming styles. ...
    (alt.lang.asm)
  • Mini-interpreter in OCaml
    ... they can be written in languages like OCaml. ... | `Int of int ... (* Make a string representation of an expression *) ... let rec string_of_value = function ...
    (comp.lang.functional)
  • Re: Need help on a dictionary table...
    ... > I need to show in several languages and I can't find the best way to ... > Column: ID, int, 4 ... > Column: Text, varchar, 50 ... > I don't know if this is a typical problem, ...
    (microsoft.public.sqlserver.olap)
  • Re: "Referenced type "
    ... object and an int value, especially in languages having proper constants. ... Both x and y are of type int, yet &x is allowed but not &y. ... `x' is an identifier, ...
    (comp.lang.c)
  • Re: Code Review - is this code shit
    ... main (int) can be invoked. ... it using some constructs that aren't portable or compiler ... Even interpreted languages have this problem. ... Richard Heathfield constantly abuses and harasses unsuspecting users ...
    (comp.lang.c)