Re: Malcolm's new book
- From: Kelsey Bjarnason <kbjarnason@xxxxxxxxx>
- Date: Thu, 2 Aug 2007 15:43:54 -0700
[snips]
On Thu, 02 Aug 2007 20:03:59 +0100, Malcolm McLean wrote:
int get_buff_len( buffer_t buff )In a 32-bit environment that is most unlikely. In a 64-bit environment,
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.
well, that's a different story.
In a 16-bit environment, entirely possible.
I explain in the opening paragraphs why size_ts will not pollute my C
code
Because they exist for a reason, they do a job ints don't do, they do it
properly, in cases where ints simply are the *wrong* type - and thus you
choose int.
As I said, a complete failure to grasp basic concepts.
. You don't disagree with this reasoning, you either haven't read it
or fail to engage with it.
I will, of course, disagree with any argument which leads to provably
wrong results, such as concluding int is the appropriate type for size
arguments where size_t is the correct choice.
If you know it, you should use it. Since there is *no* possibleIntermediate size or index calculations can easily be negative.
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.
In which case, use ints for those, if applicable. Using them to pass or
return the size of a buffer is simply wrong, as a buffer will never have a
negative size, but can have a size larger than the range of an int, making
int the wrong type to use.
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 haven't read the whole thing, but the example chapters say it's not
particularly useful *now*, since it contains your fundamental inability to
grasp basic concepts and thus persistently does the Wrong Thing. Well,
okay, it might be useful as kindling, but it is bad enough, based just on
those examples shown, that it should never be allowed anywhere near a
programmer's hands, for fear it will taint them with the same illogic and
poor designs you employ in it.
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.
Why would size_t be obsolete, since it does a job int does not do?
I can't see a language that
insists on a type called "size_t" as a general-purpose index lasting for
long.
So? It exists now, it has reasons for existing now, and you are ignoring
them and as a result producing bad, broken, amateurish code.
.
- Follow-Ups:
- Re: Malcolm's new book
- From: Malcolm McLean
- Re: Malcolm's new book
- References:
- Re: Malcolm's new book
- From: Kelsey Bjarnason
- Re: Malcolm's new book
- From: Malcolm McLean
- Re: Malcolm's new book
- Prev by Date: Re: Trivial
- Next by Date: Re: Mergring two string Arrays
- Previous by thread: Re: Malcolm's new book
- Next by thread: Re: Malcolm's new book
- Index(es):
Relevant Pages
|