size_t problems

**Martin Wells** · Sep 1 '07, 06:05 PM

Re: size_t problems

CBFalconer:

size_t Strlen(char *s) {
char *p = s;
if (p) while (*p) p++;
return p - s;
}

>
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** · Sep 1 '07, 06:25 PM

Re: size_t problems

Martin Wells <warint@eircom. netwrote:

>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.

Choose all that apply:

1. You're mistaken.

2. You're a liar.

3. You don't get very much done.

>"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.

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

**Martin Wells** · Sep 1 '07, 06:35 PM

Re: size_t problems

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.

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 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.

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

Martin

**Keith Thompson** · Sep 1 '07, 06:45 PM

Re: size_t problems

jacob navia <jacob@jacob.re mcomp.frwrites:

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).

--
Keith Thompson (The_Other_Keit h) kst-u@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** · Sep 1 '07, 07:05 PM

Re: size_t problems

"jacob navia" <jacob@jacob.re mcomp.frwrote in message
news:46d98bb2$0 $25943$ba4acef3 @news.orange.fr ...

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.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

**Richard Heathfield** · Sep 1 '07, 07:15 PM

Re: size_t problems

Keith Thompson said:

jacob navia <jacob@jacob.re mcomp.frwrites:

>>
>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.

--
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

**Malcolm McLean** · Sep 1 '07, 07:25 PM

Re: size_t problems

"Martin Wells" <warint@eircom. netwrote in message
news:1188671171 .922636.119090@ d55g2000hsg.goo glegroups.com.. .

Ed Jensen
>

>Choose all that apply:
>>
>1. You're mistaken.
>>
>2. You're a liar.
>>
>3. You don't get very much done.

>
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.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

**Malcolm McLean** · Sep 1 '07, 07:25 PM

Re: size_t problems

"Martin Wells" <warint@eircom. netwrote in message
news:1188667439 .993226.123110@ 57g2000hsv.goog legroups.com...

Malcolm McLean
#include <stddef.h>
>
void AddFiveToEachEl ement(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 AddFiveToEachEl ementsz(size_t *p, size_t len)

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

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

**Malcolm McLean** · Sep 1 '07, 07:35 PM

Re: size_t problems

"Martin Wells" <warint@eircom. netwrote in message
news:1188669620 .856942.29840@5 0g2000hsm.googl egroups.com...

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.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

**Ben Pfaff** · Sep 1 '07, 07:55 PM

Re: size_t problems

"Malcolm McLean" <regniztar@btin ternet.comwrite s:

"Martin Wells" <warint@eircom. netwrote in message
news:1188667439 .993226.123110@ 57g2000hsv.goog legroups.com...

>#include <stddef.h>
>>
>void AddFiveToEachEl ement(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 AddFiveToEachEl ementsz(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.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

**Peter J. Holzer** · Sep 1 '07, 08:05 PM

Re: size_t problems

On 2007-09-01 19:21, Malcolm McLean <regniztar@btin ternet.comwrote :

"Martin Wells" <warint@eircom. netwrote in message
news:1188667439 .993226.123110@ 57g2000hsv.goog legroups.com...

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

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 AddFiveToEachEl ementsz(size_t *p, size_t len)

so we need another version

void AddFiveToEachEl ementLong(long *p, size_t len)

and another one

void AddFiveToEachEl ementDouble(dou ble *p, size_t len)

and another one

void AddFiveToEachEl ementLongLong(l ong long *p, size_t len)

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

**Ben Pfaff** · Sep 1 '07, 08:05 PM

Re: size_t problems

"Malcolm McLean" <regniztar@btin ternet.comwrite s:

"Martin Wells" <warint@eircom. netwrote in message
news:1188669620 .856942.29840@5 0g2000hsm.googl egroups.com...

>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.

4 times faster *is* a hell of a lot faster. Asymptotic
performance is not what the world is all about. In the end it's
all about how fast you can finish a particular task. The
asymptotic complexity of me adding numbers by hand is the same as
if the computer does it, but I tend to let the computer do it.
It's faster.
--
"The expression isn't unclear *at all* and only an expert could actually
have doubts about it"
--Dan Pop

**Peter J. Holzer** · Sep 1 '07, 08:15 PM

Re: size_t problems

On 2007-09-01 19:25, Malcolm McLean <regniztar@btin ternet.comwrote :

"Martin Wells" <warint@eircom. netwrote in message
news:1188669620 .856942.29840@5 0g2000hsm.googl egroups.com...

>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,

Probably less.

which makes it O(N), which means it is about as fast as the canonical
loop.

**jacob navia** · Sep 1 '07, 08:15 PM

Re: size_t problems

Peter J. Holzer wrote:

On 2007-09-01 19:25, Malcolm McLean <regniztar@btin ternet.comwrote :

>"Martin Wells" <warint@eircom. netwrote in message
>news:118866962 0.856942.29840@ 50g2000hsm.goog legroups.com...

>>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,

>
Probably less.
>

>which makes it O(N), which means it is about as fast as the canonical
>loop.

>
By that kind of reasoning a snail is about as fast as a jet.
>
hp
>
>

Most of the strings in this application are less than 80 bytes long.

The difference is zero!

It is all swamped in the overhead of function call, and loop setup!

jacob

**Mark McIntyre** · Sep 1 '07, 08:25 PM

Re: size_t problems

On Sat, 01 Sep 2007 20:51:34 +0200, in comp.lang.c , jacob navia
<jacob@jacob.re mcomp.frwrote:

>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.

So? in any typical application, all the above interface specific stuff
can (and should) be separated from the meat of the programme.

>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.

Hey, didn't someone invent a new language cos they had similar issues,
remind us what its called?

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

or they practice good progamming technique and isolate interface code
into different (and replaceable) libraries.

--
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

size_t problems

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment