size_t problems

[Martin Wells]

Malcolm McLean:

Yes. But psychological factors are also important. If an index variable is
called "size" then of course the compiler will happily chug through and
index the array by variable "size". However to anyone reading the program it
is intensely irritating.

typedef size_t index_t;

Martin

 

[Martin Wells]

Ian Collins:

That's because it can be written without the cast.

The cast is there to suppress a compiler warning. Anyway it seems we
disagree fundamentally on this so I don't think there's much point in
discussing it, other than a constant "I like cast" reply to "I don't
like cast".

Do you know of a "decent compiler" that does?

gcc.

Martin

 

[Martin Wells]

jacob navia:

Look, it is not the C standard that runs my code.

It is a mindless processor, churning instruction after instruction, no
mind no standards, no nothing.

I have an aesthetic view of code. What is important in it, from my
viewpoint, is clarity of design and above all, that
IT WORKS.

There is a price to be paid for this: Lack of portability.

You are now paying that price, and the headache you now suffer is the
fruit of your own actions.

Portability seems to be a key issue on this newsgroup, which is why
you aren't getting the replies you desire.

Martin

 

[Martin Wells]

Malcolm McLean

Two things will happen.
Probably there will be a howl of protest as desktop programs move from 32 to
64 bits, and the implications of size_t being no longer the same size as an
int (give or take a sign bit) become obvious. So something will be done, and
people will look at code saying size_t i and say "Oh, that garbage the
committee inisted on back in 2007? What obsolete code."

The other possibility is that the committee will have its way, and we've all
got to write size_t for practically every array index. This makes C a
difficult language, OK for the specialist, but not very good for beginner
use. So it is no longer a good choice for a beginning book. Either use a
different language, or use a cut down, simplified version of the existing
language, with a note to say what you've done.

Am I the only one who doesn't acknowledge any problems when moving
from 32-Bit to 64-Bit? That is to say, am I the only one who's being
using size_t properly?

Someone please tell me why it's so difficult to use size_t in the
following fashion:

#include <stddef.h>

void AddFiveToEachElement(int *p,size_t len)
{
while (len--) *p++ += 5;
}

If you throw portability out the window, as jacob navia has done, then
you are ASKING FOR THESE PROBLEMS. You're lighting a fuse... it may be
a very long fuse, but it eventually will go off.

Martin

 

[Martin Wells]

Ed Jensen:

1. Writing 100% portable code. This can be non-trivial and really
slow down your development. (However, I'm sure writing 100% portable
code doesn't slow down any of the geniuses HERE. I'm talking strictly
about MORTAL developers.)

I don't consider myself to be an Einstein by any stretch of the
imagination, but still I've no problem keeping my code portable.
Likely reason being that I focused on that fashion of programming
rather than played around with int's all the time.

"Well, just write your C code so it's 100% portable in the first
place. Easy! Problem solved! Only dummies don't do that!"

Writing portable code is really a hell of a lot easier, and even a
hell of a lot more satisfying, than you make it sound.

Martin

 

[Martin Wells]

CBFalconer:

AFAICS this has the same action as strlen.

Just as an example, the strlen on Microsoft Windows compilers test
entire 4-byte chunks at a time looking for a byte which is all zeros.
It's a hell of a lot faster than using a canonical loop.

Martin

 

[Ed Jensen]

False. The portable writer reaches for the earlier developed
routines, all tested, and incorporates them. Then he goes
swimming, or something else enjoyable.

And then we ride to work over rainbows on ponies!

 

[CBFalconer]

CBFalconer:


Just as an example, the strlen on Microsoft Windows compilers test
entire 4-byte chunks at a time looking for a byte which is all
zeros. It's a hell of a lot faster than using a canonical loop.

Well, I wasn't clear. I meant as a black box, not as to code.

 

[Ed Jensen]

I don't consider myself to be an Einstein by any stretch of the
imagination, but still I've no problem keeping my code portable.
Likely reason being that I focused on that fashion of programming
rather than played around with int's all the time.

Choose all that apply:

1. You're mistaken.

2. You're a liar.

3. You don't get very much done.

Writing portable code is really a hell of a lot easier, and even a
hell of a lot more satisfying, than you make it sound.

Writing extremely portable code IS easy, just not in C.

 

[Martin Wells]

Ed Jensen

Choose all that apply:

1. You're mistaken.

2. You're a liar.

3. You don't get very much done.

I'll have to go with number 1. Sorry I'll try again:

Writing portable code in C is VERY easy.

Yeah that sounds about right.

Writing extremely portable code IS easy, just not in C.

Now you're just preaching about your own incompetence. Sorry to sound
hostile, but it's the truth.

Martin

 

[Keith Thompson]

Ed Jensen wrote: [...]

"Well, just write your C code so it's 100% portable in the first
place. Easy! Problem solved! Only dummies don't do that!"

And then, like heathfield, they discover that they published a book
(c unleashed) with in one page the assumption that
sizeof(int) == sizeof(int *).

[...]

Yes, well, that's quite an effective refutation of Richard's claim
that he's infallible.

Except that he's never made such a claim.

He (or one of his co-authors) made a mistake. So what? That doesn't
affect his ability to offer good advice (which is checked for accuracy
by other readers here).

 

[jacob navia]

And then we ride to work over rainbows on ponies!

Standard C doesn't have

1) Any serious i/o. To do anything fast you need system specific stuff.
2) Any notion of the keyboard. To handle the keyboard you need system
specific stuff.
3) Any graphics. Ditto.
4) No network.
5) Not any timers with reasonable accuracy.

C is very popular for systems programming but none of those programs
is written in standard C.

I am porting the lcc-win IDE and debugger. Written in C but system
specific. And I do not give a damm about portability of a windows
debugger to the latest toaster with embedded linux

Windows debuggers aren't very portable outside windows as you may know.

It would be possible to at least do something reasonable portable if the
standard would specify a reasonable string library, a common container
library, a common base for using in day to day programming.

Nope there isn't anything like that in portable standard C.


All this people talking about "Portable standard C" are just talking
nonsense.

Or they do not use the network, nor do they do any graphics, nor do they
use any i/o, etc etc.

Yes, for toy applications it is barely portable, but even this program:

#include <stdio.h>
int main(void){printf("hello\n");}

is portable since the errors of printf are NOT specified, so you have no
way to know what happened if printf returns a negative result, besides
going into implementation specific stuff!

 

[Malcolm McLean]

Ed Jensen wrote:
And then, like heathfield, they discover that they published a book
(c unleashed) with in one page the assumption that
sizeof(int) == sizeof(int *).

It is easy to play the guru here. More difficult in reality.

It is also a lot easier to find errors in books than to write one. Having
been through the same process I won't criticise Heathfield too much. They
can creep in during formatting as well as in development and testing. My
book had some errors as well.

 

[Malcolm McLean]

And then we ride to work over rainbows on ponies!

Don't. I was really looking forwards to working on Barbie and My Little
Pony. Then we lost the contract and the company went bankrupt.

 

[Richard Heathfield]

Keith Thompson said:

And then, like heathfield, they discover that they published a book
(c unleashed) with in one page the assumption that
sizeof(int) == sizeof(int *).

[...]

Yes, well, that's quite an effective refutation of Richard's claim
that he's infallible.

Except that he's never made such a claim.

Right (except in jest, of course). Nevertheless, don't assume that Mr
Navia's claim is correct without checking. It might be, of course, but
then again, it might not be.

He (or one of his co-authors) made a mistake.

Quite a few, alas. I don't recall any instances of assuming sizeof(int)
to be equal to sizeof(int *), but it's certainly possible. In the
absence of a more specific reference, however, I will assume that his
bug report has as much substance behind it as everything else he posts.
If I'm wrong to assume this, doubtless I'll find out in due course.

 

[Malcolm McLean]

Ed Jensen


Now you're just preaching about your own incompetence. Sorry to sound
hostile, but it's the truth.

No, limited experience, Not the same thing as incompetence at all.

If you write say, mainly code to drive GUIs under Windows, you will find
that there's little point making much portable. Everything has to be ripped
up and rewritten whenever the denizens of Redmond decide to realease a new
compiler anyway.

However if you are writing mostly scientific programs, as I am doing at
present, everything has got to be portable. I've no business writing code
that can't be shifted to a mainframe or PC or whatever, as need arises. And
the graphical routines are in separate programs; the Beowulf cluster has a
simple teletype-style terminal as its communication with the outside world.

Even slash slash comments, which I thought were surely as good as standard
by now, are not accepted by the parallel compiler.

 

[Malcolm McLean]

Malcolm McLean
#include <stddef.h>

void AddFiveToEachElement(int *p,size_t len)
{
while (len--) *p++ += 5;
}

If you throw portability out the window, as jacob navia has done, then
you are ASKING FOR THESE PROBLEMS. You're lighting a fuse... it
may be a very long fuse, but it eventually will go off.

What are those ints going to be used for? We don't know, but such a useful
function would surely find a place in calculating array indices, or
intermediate values, such as counts, to calculating array indices.

So we need another version

void AddFiveToEachElementsz(size_t *p, size_t len)

The fuse has gone off. That's what the admission of size_t does to your
code.

 

[Malcolm McLean]

CBFalconer:
Just as an example, the strlen on Microsoft Windows compilers test
entire 4-byte chunks at a time looking for a byte which is all zeros.
It's a hell of a lot faster than using a canonical loop.

No it's not. It's 4 times faster, which makes it O(N), which means it is
about as fast as the canonical loop.
Every man and his dog invents a new C strign library which performs the
length operation in O(constant) time.

 

[Ben Pfaff]

What are those ints going to be used for? We don't know, but such a
useful function would surely find a place in calculating array
indices, or intermediate values, such as counts, to calculating array
indices.

So we need another version

void AddFiveToEachElementsz(size_t *p, size_t len)

The fuse has gone off. That's what the admission of size_t does to
your code.

You need a version of the function for every single type that
might need to have 5 added to it. Adding size_t to the mix
doesn't change that very much.

 

[Peter J. Holzer]

What are those ints going to be used for? We don't know, but such a useful
function would surely find a place in calculating array indices, or
intermediate values, such as counts, to calculating array indices.

No doubt it would also be very useful to calculating file offsets, which
are long

.... and trade flows which are doubles

.... and bank balances which are long long

So we need another version

void AddFiveToEachElementsz(size_t *p, size_t len)

so we need another version

void AddFiveToEachElementLong(long *p, size_t len)

and another one

void AddFiveToEachElementDouble(double *p, size_t len)

and another one

void AddFiveToEachElementLongLong(long long *p, size_t len)

The fuse has gone off. That's what the admission of size_t does to your
code.

and the admission of long, double, long long or any other type.

Let's face it, admitting types to C was a mistake.
We should go back to B.

hp