return the start of a substring in a string in c

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:tZ*********************@bt.com...

yi*****@gmail.com said:

>Hi,
In java, there is an 'indexOf' function in String which does this:

indexOf(String str)
Returns the index within this string of the first occurrence
of the specified substring.

is there anything like that in c?

The closest thing I can find is strchr, but it check for a character,
not a substring?

strstr returns a pointer to the substring - if this is non-NULL,
subtract the address of the main string from it to get the index.

ie;

char *str = "astring";
char *substring = "in";
char *ptr;
ptrdiff_t index; /* should be an int. Horrid horrid horrid */

ptr = strstr(str, substring);
if(ptr)
{
index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);
}

As an exercise to the regs, why do we need that horrid, horrid cast in the
call to printf?

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

Jul 14 '07 #3

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

Malcolm McLean wrote:

char *str = "astring";
char *substring = "in";
char *ptr;
ptrdiff_t index; /* should be an int. Horrid horrid horrid */

ptr = strstr(str, substring);
if(ptr)
{
index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);
}

As an exercise to the regs, why do we need that horrid, horrid cast in the
call to printf?

You don't. You're already assuming that index will fit in an int, so you can
just change the declaration of index to match.

Jul 14 '07 #4

Ralf Kunz

yi*****@gmail.com schrieb:

Hi,
In java, there is an 'indexOf' function in String which does this:

indexOf(String str)
Returns the index within this string of the first occurrence
of the specified substring.

is there anything like that in c?

The closest thing I can find is strchr, but it check for a character,
not a substring?

Thank you.

hello,

you can use instead the function
char * strstr(const char *s1, const char *s2)

from string.h

Ralf

Jul 14 '07 #5

"Harald van D?k" <tr*****@gmail.comwrote in message
news:f7**********@news1.zwoll1.ov.home.nl...

Malcolm McLean wrote:
>char *str = "astring";
char *substring = "in";
char *ptr;
ptrdiff_t index; /* should be an int. Horrid horrid horrid */

ptr = strstr(str, substring);
if(ptr)
{
index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);
}

As an exercise to the regs, why do we need that horrid, horrid cast in
the
call to printf?

You don't. You're already assuming that index will fit in an int, so you
can
just change the declaration of index to match.

My point exactly. We fill the language with gibberish types, which don't
actually gain anything because eventually some fucntion somewhere will
expect an int.
Join the campaign for 64 bit ints and this nonsense will fade away.

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

Jul 14 '07 #6

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

Malcolm McLean wrote:

"Harald van D?k" <tr*****@gmail.comwrote in message
news:f7**********@news1.zwoll1.ov.home.nl...
>Malcolm McLean wrote:
>>char *str = "astring";
char *substring = "in";
char *ptr;
ptrdiff_t index; /* should be an int. Horrid horrid horrid */

ptr = strstr(str, substring);
if(ptr)
{
index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);
}

As an exercise to the regs, why do we need that horrid, horrid cast in
the
call to printf?

You don't. You're already assuming that index will fit in an int, so you
can
just change the declaration of index to match.

My point exactly. We fill the language with gibberish types, which don't
actually gain anything because eventually some fucntion somewhere will
expect an int.

Which function is that, here? You don't need to assume index will fit in an
int, you just chose to for convenience.

Jul 14 '07 #7

"Harald van DÄ³k" <tr*****@gmail.comwrote in message
news:f7*********@news3.zwoll1.ov.home.nl...

Malcolm McLean wrote:
>"Harald van D?k" <tr*****@gmail.comwrote in message
news:f7**********@news1.zwoll1.ov.home.nl...
>>Malcolm McLean wrote:
char *str = "astring";
char *substring = "in";
char *ptr;
ptrdiff_t index; /* should be an int. Horrid horrid horrid */

ptr = strstr(str, substring);
if(ptr)
{
index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);
}

As an exercise to the regs, why do we need that horrid, horrid cast in
the
call to printf?

You don't. You're already assuming that index will fit in an int, so you
can
just change the declaration of index to match.

My point exactly. We fill the language with gibberish types, which don't
actually gain anything because eventually some fucntion somewhere will
expect an int.

Which function is that, here? You don't need to assume index will fit in
an
int, you just chose to for convenience.

printf(). There probably is a specifier for ptrdiff_t in C99, but I doubt
you can guarantee its presence.

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

Jul 14 '07 #8

Army1987

On Sat, 14 Jul 2007 07:29:35 +0100, Malcolm McLean wrote:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:tZ*********************@bt.com...
>yi*****@gmail.com said:

>>Hi,
In java, there is an 'indexOf' function in String which does this:

indexOf(String str)
Returns the index within this string of the first occurrence
of the specified substring.

is there anything like that in c?

The closest thing I can find is strchr, but it check for a character,
not a substring?

strstr returns a pointer to the substring - if this is non-NULL,
subtract the address of the main string from it to get the index.

ie;

char *str = "astring";
char *substring = "in";
char *ptr;
ptrdiff_t index; /* should be an int. Horrid horrid horrid */

ptr = strstr(str, substring);
if(ptr)
{
index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);
}

As an exercise to the regs, why do we need that horrid, horrid cast in the
call to printf?

Because you feared enough that the magnitude of (ptr - str) could
ever be 32767, that you didn't declare index as an int.
Otherwise you could declare it as a long and use "%ld" in printf.
--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

Jul 14 '07 #9

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

Malcolm McLean wrote:

"Harald van DÄ³k" <tr*****@gmail.comwrote in message
news:f7*********@news3.zwoll1.ov.home.nl...
>Malcolm McLean wrote:
>>"Harald van D?k" <tr*****@gmail.comwrote in message
news:f7**********@news1.zwoll1.ov.home.nl...
Malcolm McLean wrote:
char *str = "astring";
char *substring = "in";
char *ptr;
ptrdiff_t index; /* should be an int. Horrid horrid horrid */
>
ptr = strstr(str, substring);
if(ptr)
{
index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);
}
>
As an exercise to the regs, why do we need that horrid, horrid cast in
the
call to printf?

You don't. You're already assuming that index will fit in an int, so
you can
just change the declaration of index to match.

My point exactly. We fill the language with gibberish types, which don't
actually gain anything because eventually some fucntion somewhere will
expect an int.

Which function is that, here? You don't need to assume index will fit in
an
int, you just chose to for convenience.

printf(). There probably is a specifier for ptrdiff_t in C99,

Indeed there is.

but I doubt
you can guarantee its presence.

#if __STDC_VERSION__ >= 199901L
ptrdiff_t index = ptr - str;
printf("your substring was found at postion %td (0-based)\n", index);
#else
long index = ptr - str;
printf("your substring was found at postion %ld (0-based)\n", index);
#endif

C99 has a specifier for ptrdiff_t. C90 has a guarantee that ptrdiff_t is no
wider than long. If neither applies, you're not dealing with an
implementation of standard C. (Yes, I'm aware that there are real-world
C-like implementations that do not conform to any standard.)

Jul 14 '07 #10

Malcolm McLean wrote, On 14/07/07 09:34:

>
"Harald van D?k" <tr*****@gmail.comwrote in message
news:f7**********@news1.zwoll1.ov.home.nl...
>Malcolm McLean wrote:
>>char *str = "astring";
char *substring = "in";
char *ptr;
ptrdiff_t index; /* should be an int. Horrid horrid horrid */

ptr = strstr(str, substring);
if(ptr)
{
index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);
}

As an exercise to the regs, why do we need that horrid, horrid cast
in the
call to printf?

You don't. You're already assuming that index will fit in an int, so
you can
just change the declaration of index to match.

My point exactly. We fill the language with gibberish types,

You may consider them gibberish, but others don't.

which don't
actually gain anything because eventually some fucntion somewhere will
expect an int.

Only if you make the choice to do that.

Join the campaign for 64 bit ints and this nonsense will fade away.

As has been pointed out before, it seems to be a one man campaign
which has been started after all the key decisions have been made and
the key implementations have selected 32 bit ints. To statnd a chance
you need to work on what will be done with 128 bit processors, not 64
bit processors where it is done and dusted.
--
Flash Gordon

Jul 14 '07 #11

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:33************@news.flash-gordon.me.uk...

Malcolm McLean wrote, On 14/07/07 09:34:
>>
"Harald van D?k" <tr*****@gmail.comwrote in message
news:f7**********@news1.zwoll1.ov.home.nl...
>>Malcolm McLean wrote:
char *str = "astring";
char *substring = "in";
char *ptr;
ptrdiff_t index; /* should be an int. Horrid horrid horrid */

ptr = strstr(str, substring);
if(ptr)
{
index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);
}

As an exercise to the regs, why do we need that horrid, horrid cast in
the
call to printf?

You don't. You're already assuming that index will fit in an int, so you
can
just change the declaration of index to match.

My point exactly. We fill the language with gibberish types,

You may consider them gibberish, but others don't.

which don't
actually gain anything because eventually some fucntion somewhere will
expect an int.

Only if you make the choice to do that.

>Join the campaign for 64 bit ints and this nonsense will fade away.

As has been pointed out before, it seems to be a one man campaign
which has been started after all the key decisions have been made and the
key implementations have selected 32 bit ints. To statnd a chance you need
to work on what will be done with 128 bit processors, not 64 bit
processors where it is done and dusted.

It is still a one-man campaign. I am anxious to turn it into a 2-man
campaign.
It is not obvious what to do with 128 bits. The point is that integers
usually count things, but it is unlikely that there will ever be enough
memory in a machine to overflow a 64 bit int. I almost said enough memory
manufactured, but in fact a world of 4 billion machines with 4GB each is
perfectly foreseeable.

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

Jul 14 '07 #12

"Malcolm McLean" <re*******@btinternet.comwrites:

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:33************@news.flash-gordon.me.uk...
>Malcolm McLean wrote, On 14/07/07 09:34:
>>Join the campaign for 64 bit ints and this nonsense will fade away.

As has been pointed out before, it seems to be a one man campaign
which has been started after all the key decisions have been made
and the key implementations have selected 32 bit ints. To statnd a
chance you need to work on what will be done with 128 bit
processors, not 64 bit processors where it is done and dusted.

It is still a one-man campaign. I am anxious to turn it into a 2-man
campaign.
It is not obvious what to do with 128 bits. The point is that integers
usually count things, but it is unlikely that there will ever be
enough memory in a machine to overflow a 64 bit int.

Why do say integers usually count things? Don't you ever calculate
things with integers? I used to work on projects (cryptography stuff)
where calculating was more common than counting and ints were
always too short. Counting is usually done with integers, but you
can't turn that round the other way.

--
Ben.

Jul 14 '07 #13

Stephen Sprunk

<yi*****@gmail.comwrote in message
news:11**********************@d55g2000hsg.googlegr oups.com...

Hi,
In java, there is an 'indexOf' function in String which does this:

indexOf(String str)
Returns the index within this string of the first occurrence
of the specified substring.

is there anything like that in c?

The closest thing I can find is strchr, but it check for a character,
not a substring?

If you know strchr() searches a string for a char, did it not occur to you
to check if strstr() searches a string for a string?

However, both return a pointer to the first instance found (or NULL, if
none) instead of an index. If the returned value was non-NULL, subtract the
pointer to the original string from the returned value to get the index.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

Jul 14 '07 #14

Ben Bacarisse wrote, On 14/07/07 13:43:

"Malcolm McLean" <re*******@btinternet.comwrites:

>"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:33************@news.flash-gordon.me.uk...
>>Malcolm McLean wrote, On 14/07/07 09:34:
Join the campaign for 64 bit ints and this nonsense will fade away.
As has been pointed out before, it seems to be a one man campaign
which has been started after all the key decisions have been made
and the key implementations have selected 32 bit ints. To statnd a
chance you need to work on what will be done with 128 bit
processors, not 64 bit processors where it is done and dusted.

It is still a one-man campaign. I am anxious to turn it into a 2-man
campaign.

Your approach on this group is more likely to make people campaign
against you.

>It is not obvious what to do with 128 bits. The point is that integers
usually count things, but it is unlikely that there will ever be
enough memory in a machine to overflow a 64 bit int.

Why do say integers usually count things? Don't you ever calculate
things with integers? I used to work on projects (cryptography stuff)
where calculating was more common than counting and ints were
always too short. Counting is usually done with integers, but you
can't turn that round the other way.

We've been through this before with Malcolm, he seems unable to
comprehend that a lot of peoples experience does not match his. and that
it is only his personal opinion which he has been unable to give any
convincing evidence for, let alone proof.
--
Flash Gordon

Jul 14 '07 #15

"Ben Bacarisse" <be********@bsb.me.ukwrote in message

Why do say integers usually count things? Don't you ever calculate
things with integers? I used to work on projects (cryptography stuff)
where calculating was more common than counting and ints were
always too short. Counting is usually done with integers, but you
can't turn that round the other way.

As Flash says, we've been through all this before. I even pulled up some
Java stats that showed pretty clearly that there were about as many indexed
array accesses as integer operations in a sample of Java programs. I
couldn't find a similar study for C, though I didn't try too hard, but there
is no reason to suppose that C programs are radically different from Java
ones.

Computers spend most of their cycles moving data from one place to another,
and most integers are used to count things in the computer's memory. That's
not every cycle, of course, nor is every single integer a count of
something - cryptography is an obvious exception, as are intermediate
results in frequency transforms, or pixel colours. The last leads us to
another issue, in a typical image function

void setpixel(long *img, int width, int height, int x, int y, long val)
{
assert(x >= 0 && x < width);
assert*y >= 0 && y < height);
img[y*width + x] = height;
}

How many integers do we have? You could say width * height, plus a few, or
you could say six, of which two are pixel values and four intermediates in
array calculations. I'm counting it as six, which isn't the only answer
justifiable, but makes sense in the context of how best to define the types
in a high-level language.

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

Jul 14 '07 #16

Keith Thompson

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

My point exactly. We fill the language with gibberish types, which
don't actually gain anything because eventually some fucntion
somewhere will expect an int.
Join the campaign for 64 bit ints and this nonsense will fade away.

Your best approach, I think, would be to take an existing compiler and
modify it so it supports only the 64-bit int that you want.
(Presumably you would drop short, long, and long long; I'm guessing
you'd still want unsigned int, but that's up to you.) You could then
use your customized compiler for your own programming.

It's likely that nobody else would be interested in using it. But if
you're right, everyone else is wrong, and your approach is better than
what we've been doing for the past several decades, then an existing
compiler could be the best way to spread your unusual ideas.

--
Keith Thompson (The_Other_Keith) ks***@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"

Jul 14 '07 #17

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:uc************@news.flash-gordon.me.uk...

>
If you want to say it is anything other than personal opinion then find
some evidence, otherwise stop claiming your personal opinion is reality.
I.e. either find a study designed to prove your point or get your
university to fund one and do it properly. I'm sure the stats department
can tell you how to design a proper study, including telling you that you
need to find a large enough *representative* sample.

That's a very common fallacy. I can find some objection to your evidence,
therefore you have offered a "no evidence" position.
Eg Martha saw Fred do the murder. But Martha is Fred's ex-mistress.
Therefore there is no evidence against Fred. No. It's plausible that an
ex-mistress would want to frame someone for murder, but not very likely
given the risks.

>
I'm not the only one to have expressed a dissenting opinion, an I don't
think I've seen anyone agree with you. Ever considered that if no one
supports you then the experience of most people here disagrees with you
and that therefore it might be you that is wrong?

I haven't seen anyone really demolish my claim that most processor cycles
are consumed in moving data from place to another. Generally what is offered
is "I can write a program where that isn't true" or "my subjective opinion
is otherwise because I do X, which involves a lot of integer calculation".
That is weak because we naturally say "the spreadheet is calculating an
average". It is, and that is point of the operation. However really it is
updating a video display.

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

Jul 14 '07 #18

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]
>My point exactly. We fill the language with gibberish types, which
don't actually gain anything because eventually some fucntion
somewhere will expect an int.
Join the campaign for 64 bit ints and this nonsense will fade away.

Your best approach, I think, would be to take an existing compiler and
modify it so it supports only the 64-bit int that you want.
(Presumably you would drop short, long, and long long; I'm guessing
you'd still want unsigned int, but that's up to you.) You could then
use your customized compiler for your own programming.

It's likely that nobody else would be interested in using it. But if
you're right, everyone else is wrong, and your approach is better than
what we've been doing for the past several decades, then an existing
compiler could be the best way to spread your unusual ideas.

It is an idea. I could modify the GNU front end, and it would probably be
quite trivial, though quite hard to understand the code structure.
However the vast majority of my programming has to work on anything, which
is partly why having several integer types is such a nuisance.

ints have been able to address all of memory space, with the unimportant
exception of strings or char arrays which occupy more than 50% of memory, of
the vast majority of machines up till now. The advent of 64 bits onto the
desktop will change that.

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

Jul 14 '07 #19

"Malcolm McLean" <re*******@btinternet.comwrote in message
news:ta*********************@bt.com...

>
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>"Malcolm McLean" <re*******@btinternet.comwrites:
[...]
>>My point exactly. We fill the language with gibberish types, which
don't actually gain anything because eventually some fucntion
somewhere will expect an int.
Join the campaign for 64 bit ints and this nonsense will fade away.

Your best approach, I think, would be to take an existing compiler and
modify it so it supports only the 64-bit int that you want.
(Presumably you would drop short, long, and long long; I'm guessing
you'd still want unsigned int, but that's up to you.) You could then
use your customized compiler for your own programming.

It's likely that nobody else would be interested in using it. But if
you're right, everyone else is wrong, and your approach is better than
what we've been doing for the past several decades, then an existing
compiler could be the best way to spread your unusual ideas.

It is an idea. I could modify the GNU front end, and it would probably be
quite trivial, though quite hard to understand the code structure.
However the vast majority of my programming has to work on anything, >
which is partly why having several integer types is such a nuisance.

On second thoughts, the snag is the linker. If integers are passed by
address, which is by no means uncommon, you have to rebuild every library.
This only needs doing once, but it means that to be practical the decision
cannot be taken by one person, because every library has to be run through
the new compiler. Or you've got to make major changes to gcc so that the 64
bit C compiler is effectively a new language written on top of existing
libraries, rather than an interface to those libraries, which could be done
but isn't a simple as switching the code for "int" and "long long" in the
front end.

(You've also got the problem of library code not written in C. There will
never be a good answer to that one.)

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

Jul 14 '07 #20

Malcolm McLean wrote, On 14/07/07 20:22:

>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:uc************@news.flash-gordon.me.uk...
>>
If you want to say it is anything other than personal opinion then
find some evidence, otherwise stop claiming your personal opinion is
reality.
I.e. either find a study designed to prove your point or get your
university to fund one and do it properly. I'm sure the stats
department can tell you how to design a proper study, including
telling you that you need to find a large enough *representative* sample.

That's a very common fallacy. I can find some objection to your
evidence, therefore you have offered a "no evidence" position.
Eg Martha saw Fred do the murder. But Martha is Fred's ex-mistress.
Therefore there is no evidence against Fred. No. It's plausible that an
ex-mistress would want to frame someone for murder, but not very likely
given the risks.

Your fallacy is that an unrepresentative sample proves something. Most
people on this group post using male names, therefore most people in the
world are male.

Several reasons why you have not proved your point have been pointed out
to you, and the experience of everyone on this group who expresses an
opinion disagrees with you, so my study, which is based on a sample of C
programmers in different fields (rather than one person doing a study on
a different point with Java), by your logic proves that you are wrong.

Alternatively, we have one study for and one against, with more people
disagreeing with you than agreeing, so the balance of evidence currently
available suggests it is more likely that you are wrong than correct.

>I'm not the only one to have expressed a dissenting opinion, an I
don't think I've seen anyone agree with you. Ever considered that if
no one supports you then the experience of most people here disagrees
with you and that therefore it might be you that is wrong?

I haven't seen anyone really demolish my claim that most processor
cycles are consumed in moving data from place to another.

So your unrelated study and personal opinion are evidence, but the
experience of anyone else does not count. I think you have a very
inflated opinion of yourself.

Had more people on the group agreed with you I would have accepted that
was supporting evidence (not proof), but I don't think anyone has posted
supporting you.

Generally what
is offered is "I can write a program where that isn't true" or "my
subjective opinion is otherwise because I do X, which involves a lot of
integer calculation".

Misrepresenting what others say does not prove your point either. Others
are saying that there many years of experience in real programming in
the real world for real world applications in a variety of application
domains disagrees with your opinion.

That is weak because we naturally say "the
spreadheet is calculating an average". It is, and that is point of the
operation. However really it is updating a video display.

So you don't could the 50 your 100 integer calculations used to generate
a value, only the dozen used to calculate where to get and put data?

Your experience and opinion proves your point but the experience and
opinion of everyone else does not count? Why should anyone take account
of your experience or opinion if you don't consider the experience of
others relevant?
--
Flash Gordon

Jul 14 '07 #21

"Flash Gordon" <sp**@flash-gordon.me.ukwrote

>
So you don't could the 50 your 100 integer calculations used to generate a
value, only the dozen used to calculate where to get and put data?

That's right. if we say "most integers are used to count things" then what
matters is the final contribution of that integer to the program's output.
Normally it ends up being used as an array index. However there is almost
always some intermediate calculation, such as an increment and comparison to
step through a loop. If the intermediate calculations are very elaborate,
such as a cryptographical app that, ultimately, produces a list of indices
into a character table, then you could say that the analysis isn't too
useful because we are not really representing where the integers spend their
time. In the last example, the fact that the integer will eventually index
the character table isn't important and we are unlikely to care if it goes
through a conversion subroutine to put it into the range of the character
set. However generally the final destination will dominate our choice of
representation.

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

Jul 14 '07 #22

Malcolm McLean wrote, On 14/07/07 21:11:

"Flash Gordon" <sp**@flash-gordon.me.ukwrote
>>
So you don't could the 50 your 100 integer calculations used to
generate a value, only the dozen used to calculate where to get and
put data?

That's right. if we say "most integers are used to count things" then
what matters is the final contribution of that integer to the program's
output. Normally it ends up being used as an array index. However there

That may be your experience, but it is not mine.
So you think that in
a[b+c] = d*e*f*g*h*h;
most stuff is to do with indexing? I suggest that almost everyone would
disagree with you. Only 3 operation in the above are to do with the
indexing, all the rest are calculating a value which has nothing to do
with indexing. Most of my work actually has simpler expressions for
indexing (if there is any) and more complex expressions for calculating
the value.

To take just one real example. Starting with under a dozen numbers which
were not part of an array the processor spent on average over 20ms doing
3 dimensional geometry mostly in integer arithmetic for speed and
probably about 2ms doing a completely separate task which involved a
1024 element array, but in that task the output was 2 numbers.

is almost always some intermediate calculation, such as an increment and
comparison to step through a loop.

Ah, you think if there is one loop in a program then all integer
arithmetic is to do with counting, even if it is nothing to do with the
loop variable.

If the intermediate calculations are
very elaborate, such as a cryptographical app that, ultimately, produces
a list of indices into a character table, then you could say that the
analysis isn't too useful because we are not really representing where
the integers spend their time. In the last example, the fact that the
integer will eventually index the character table isn't important and we
are unlikely to care if it goes through a conversion subroutine to put
it into the range of the character set. However generally the final
destination will dominate our choice of representation.

I will leave someone who knows about cryptography to answer that.

Personally I'm starting to think you are using a very strange definition
of what counting and array indexing is to come up with your figures. I
don't consider calculating the value to put in to an array to be
anything to do with counting or indexing, I only count the calculation
of where to put it as indexing, which a lot of the time is just one or
two additions, maybe a multiplication. Calculating the value on the
other hand is often dozens or more operations.
--
Flash Gordon

Jul 14 '07 #23

Malcolm McLean wrote, On 14/07/07 20:27:

<snip>

However the vast majority of my programming has to work on anything,
which is partly why having several integer types is such a nuisance.

So use the types defined by the standard for the purposes they were
defined, then it will work. That is why different integer types are
provided for different purposes! You can even <gaspuse the values in
limits.h to find out what the limits are at compile time.

Alternatively move to Java where everything is nailed down to be the
same on all implementations (apart from my Java code that will not run
on SCO despite doing nothing exotic) however inefficient it is.

ints have been able to address all of memory space, with the unimportant
exception of strings or char arrays which occupy more than 50% of
memory, of the vast majority of machines up till now. The advent of 64
bits onto the desktop will change that.

Hold your breath whilst you wait. Of course, this will rewuire holding
your breath at least until 128 bit processors are used for desktops, but
that is your problem not mine.
--
Flash Gordon

Jul 14 '07 #24

Army1987

On Sat, 14 Jul 2007 19:29:15 +0100, Malcolm McLean wrote:

>
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
>Why do say integers usually count things? Don't you ever calculate
things with integers? I used to work on projects (cryptography stuff)
where calculating was more common than counting and ints were
always too short. Counting is usually done with integers, but you
can't turn that round the other way.

As Flash says, we've been through all this before. I even pulled up some
Java stats that showed pretty clearly that there were about as many indexed
array accesses as integer operations in a sample of Java programs. I
couldn't find a similar study for C, though I didn't try too hard, but there
is no reason to suppose that C programs are radically different from Java
ones.

Yes, I'm trying to make a point, but...
What fraction of integers is used to index arrays in this program?
#include <stdio.h>
#include <limits.h>
#define MAX 108
#define DIGITS (((CHAR_BIT * (int)sizeof(int) - 1) * 28 - 1)/ 93 + 1)
#define COLUMNS (79 / (DIGITS + 1))
#define SQR(x) ((x) * (x))
int main(void)
{
int primes[MAX] = { 2, 3, 5, 7 };
int *current = &primes[4];
int k1, k2;
size_t column = 0;
for (k1 = 11, k2 = 13; current < primes + MAX; k1 += 6, k2 += 6) {
int *cursor;
int flag = 1;
for (cursor = &primes[2]; SQR(*cursor) <= k1; cursor++)
if (k1 % *cursor == 0) {
flag = 0;
break;
}
if (flag)
*current++ = k1;
if (current == primes + MAX)
break;
flag = 1;
for (cursor = &primes[2]; SQR(*cursor) <= k2; cursor++)
if (k2 % *cursor == 0) {
flag = 0;
break;
}
if (flag)
*current++ = k2;
if (k2 INT_MAX - 6)
break;
}
for (current = primes; current < primes + MAX; current++) {
printf("%*d ", DIGITS, *current);
if (++column >= COLUMNS) {
putchar('\n');
column = 0;
}
}
if (column)
putchar('\n');
return 0;
}

--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

Jul 15 '07 #25

"Army1987" <ar******@NOSPAM.itwrote in message
news:pa****************************@NOSPAM.it...

On Sat, 14 Jul 2007 19:29:15 +0100, Malcolm McLean wrote:

>>
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
>>Why do say integers usually count things? Don't you ever calculate
things with integers? I used to work on projects (cryptography stuff)
where calculating was more common than counting and ints were
always too short. Counting is usually done with integers, but you
can't turn that round the other way.

As Flash says, we've been through all this before. I even pulled up some
Java stats that showed pretty clearly that there were about as many
indexed
array accesses as integer operations in a sample of Java programs. I
couldn't find a similar study for C, though I didn't try too hard, but
there
is no reason to suppose that C programs are radically different from Java
ones.
Yes, I'm trying to make a point, but...
What fraction of integers is used to index arrays in this program?
#include <stdio.h>
#include <limits.h>
#define MAX 108
#define DIGITS (((CHAR_BIT * (int)sizeof(int) - 1) * 28 - 1)/ 93 + 1)
#define COLUMNS (79 / (DIGITS + 1))
#define SQR(x) ((x) * (x))
int main(void)
{
int primes[MAX] = { 2, 3, 5, 7 };
int *current = &primes[4];
int k1, k2;
size_t column = 0;
for (k1 = 11, k2 = 13; current < primes + MAX; k1 += 6, k2 += 6) {
int *cursor;
int flag = 1;
for (cursor = &primes[2]; SQR(*cursor) <= k1; cursor++)
if (k1 % *cursor == 0) {
flag = 0;
break;
}
if (flag)
*current++ = k1;
if (current == primes + MAX)
break;
flag = 1;
for (cursor = &primes[2]; SQR(*cursor) <= k2; cursor++)
if (k2 % *cursor == 0) {
flag = 0;
break;
}
if (flag)
*current++ = k2;
if (k2 INT_MAX - 6)
break;
}
for (current = primes; current < primes + MAX; current++) {
printf("%*d ", DIGITS, *current);
if (++column >= COLUMNS) {
putchar('\n');
column = 0;
}
}
if (column)
putchar('\n');
return 0;
}

Malcolm (upthread)

>>Generally what
is offered is "I can write a program where that isn't true"

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

Jul 15 '07 #26

Army1987

On Sun, 15 Jul 2007 14:19:12 +0100, Malcolm McLean wrote:

>
"Army1987" <ar******@NOSPAM.itwrote in message
news:pa****************************@NOSPAM.it...
>On Sat, 14 Jul 2007 19:29:15 +0100, Malcolm McLean wrote:
>>As Flash says, we've been through all this before. I even pulled up some
Java stats that showed pretty clearly that there were about as many
indexed
array accesses as integer operations in a sample of Java programs. I
couldn't find a similar study for C, though I didn't try too hard, but
there
is no reason to suppose that C programs are radically different from Java
ones.
Yes, I'm trying to make a point, but...
What fraction of integers is used to index arrays in this program?

[snip]

>int main(void)
{
int primes[MAX] = { 2, 3, 5, 7 };
int *current = &primes[4];
int k1, k2;
size_t column = 0;
for (k1 = 11, k2 = 13; current < primes + MAX; k1 += 6, k2 += 6) {
int *cursor;
int flag = 1;
for (cursor = &primes[2]; SQR(*cursor) <= k1; cursor++)
if (k1 % *cursor == 0) {
flag = 0;
break;
}
if (flag)
*current++ = k1;
if (current == primes + MAX)
break;

[snip]

Malcolm (upthread)

>>>Generally what
is offered is "I can write a program where that isn't true"

I don't know about Java, but if it doesn't have pointer arithmetic
*cursor++ or equivalent, the above program would need far more
array indexing than C.
So

>>there
is no reason to suppose that C programs are radically different from Java
ones.

is very dubious at least.
--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

Jul 15 '07 #27

"Malcolm McLean" <re*******@btinternet.comwrites:

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
>Why do say integers usually count things? Don't you ever calculate
things with integers? I used to work on projects (cryptography stuff)
where calculating was more common than counting and ints were
always too short. Counting is usually done with integers, but you
can't turn that round the other way.

As Flash says, we've been through all this before. I even pulled up
some Java stats that showed pretty clearly that there were about as
many indexed array accesses as integer operations in a sample of Java
programs. I couldn't find a similar study for C, though I didn't try
too hard, but there is no reason to suppose that C programs are
radically different from Java ones.

I don't want to kick this off again (I missed the last one, must have
been during a break in reading c.l.c) but until Java is the language
of choice for either OS development or embedded systems there are
obvious reasons to suppose that C programs are (statistically)
different from Java ones.

That aside, I just don't know where you are going with your argument.
I was initially correcting the logical fallacy that "most integers are
used to count" is not the same as "most counting is done with
integers". If you *are* saying that "most integers are used to count"
and let us suppose that that turns out to be true, where does that
take you? How does that advance the cause for denuding C of its
(other) integer types? To put it another way, what is the problem, to
which universal 64 bit integers is the solution?

As I said, I don't want to kick this off again, so please feel free to
leave this answered if it was dealt with last time. I'll look for the
old thread if I feel I have to know.

--
Ben.

Jul 15 '07 #28

Malcolm McLean wrote, On 15/07/07 14:19:

<snip counter-example>

Malcolm (upthread)

>>>Generally what
is offered is "I can write a program where that isn't true"

So any counter to your claim does not count because it is "a program
where that isn't true."
--
Flash Gordon

Jul 15 '07 #29

Old Wolf

On Jul 14, 6:43 pm, Harald van D k <true...@gmail.comwrote:

Malcolm McLean wrote:
ptrdiff_t index; /* should be an int. Horrid horrid horrid */

index = ptr - str;
printf("your substring was found at postion %d (0-based)\n", (int)
index);

As an exercise to the regs, why do we need that horrid, horrid cast in the
call to printf?

You don't. You're already assuming that index will fit in an int, so you can
just change the declaration of index to match.

You didn't say this explicitly, so OP may have missed
it: both versions cause implementation-defined behaviour
if the value is outside of the range of an int.

I would at least make 'index' an unsigned type, since
it is meaningless for the index of the string to be
negative anyway; and then you don't get any UB either.

Jul 15 '07 #30

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

"Malcolm McLean" <re*******@btinternet.comwrites:

The analogy did not help me. I am still stuck on this: "what is the
problem that you are campaigning to solve?". I thought you wanted all
integer types to be 64 bits, but it seems that all you want is for
undecorated "int" to 64 bits on 64 bit processors. What problem does
that solve?

It means that we almost never need anything other than an undecorated int.
In the nineteenth century Sir Joseph Whitworth stadnardised screw threads.
No longer did you need the matching nut for a bolt - all bolts and nuts
would match. Superficially that might seem a small change. In fact it was
one of the seminal events of the Industrial Revolution.
Standardising on 64 bit integers will have a similar effect on the
productivity of C programmers.

However we've got to move by stages. Just to ban "short" and "long" would
break too much code. So first they become rare, then deprecated, then they
map to 64 bits unless you compile with a separate flag. Finally they are
removed from the language, and it becomes simpler rather than more
complicated.

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

Jul 16 '07 #31

Malcolm McLean wrote, On 16/07/07 20:14:

>
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...
>"Malcolm McLean" <re*******@btinternet.comwrites:

The analogy did not help me. I am still stuck on this: "what is the
problem that you are campaigning to solve?". I thought you wanted all
integer types to be 64 bits, but it seems that all you want is for
undecorated "int" to 64 bits on 64 bit processors. What problem does
that solve?

It means that we almost never need anything other than an undecorated int.
In the nineteenth century Sir Joseph Whitworth stadnardised screw
threads.

He did not successfully standardise nuts and bolts though, only certain
aspects of them.

No longer did you need the matching nut for a bolt - all bolts
and nuts would match.

So why does my M5 nut not fit my M6 bolt?

Superficially that might seem a small change. In
fact it was one of the seminal events of the Industrial Revolution.
Standardising on 64 bit integers will have a similar effect on the
productivity of C programmers.

The int type not being 64 bits does not slow me down. Not having smaller
integer types than 64 bits, on the other hand, would significantly slow
down one of the pieces of SW I work on, SW which is already slow enough
on some tasks that people wait noticeable amounts of time. The reason it
is slow is because it is IO (specifically disk) bound, and that is why
going to a larger integer type would slow it down.

However we've got to move by stages. Just to ban "short" and "long"
would break too much code. So first they become rare, then deprecated,
then they map to 64 bits unless you compile with a separate flag.
Finally they are removed from the language, and it becomes simpler
rather than more complicated.

Alternatively you can change to a language that already meets your
requirements since there are plenty to choose from.

Oh, and if you ban having larger integer types than 64 bit (which you
seem to be proposing) you will also prevent people taking easy advantage
of newer HW that supports 128 bit or 256 bit operations, something that
would be very useful in some fields, such as cryptography, and most
people who use computers these days use some cryptographic SW whether
they know it or not.
--
Flash Gordon

Jul 16 '07 #32

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:t4************@news.flash-gordon.me.uk...

>
So why does my M5 nut not fit my M6 bolt?

Superficially that might seem a small change. In
fact it was one of the seminal events of the Industrial Revolution.
Standardising on 64 bit integers will have a similar effect on the
productivity of C programmers.

The int type not being 64 bits does not slow me down.

That was probably what the craftsmen said. The nut comes screwed onto the
bolt anyway. Sometimes you need a thick thread for a heavy duty one,
othertimes a shallow thread is cheaper. Thnen there's always one situation
where we need M5 bolts instead of M6.
In fact standardisation realsied something. But it won't necessarily ossify
the language for all time. Having pared down C to three data types; reals,
characters and integers, it might make sense to build it up again, maybe by
adding complexes or symbols like PI, e and surds. If there are about twenty
integer types that becomes much more difficult. In practise what will happen
will be that the language will become unwieldy and be abandoned.

>
Oh, and if you ban having larger integer types than 64 bit (which you seem
to be proposing) you will also prevent people taking easy advantage of
newer HW that supports 128 bit or 256 bit operations, something that would
be very useful in some fields, such as cryptography, and most people who
use computers these days use some cryptographic SW whether they know it or
not.

You probably don't want to write your bignum arithmetical ops in C anyway.
If you are relying on particular machine instructions being avialable to get
needed performance, assembly is still the way to go. We are talking about
literally half a dozen functions, of which only div mod is likely to be
non-trivial.

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

Jul 16 '07 #33

"Malcolm McLean" <re*******@btinternet.comwrites:

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...
>"Malcolm McLean" <re*******@btinternet.comwrites:

The analogy did not help me. I am still stuck on this: "what is the
problem that you are campaigning to solve?". I thought you wanted all
integer types to be 64 bits, but it seems that all you want is for
undecorated "int" to 64 bits on 64 bit processors. What problem does
that solve?

It means that we almost never need anything other than an undecorated int.
In the nineteenth century Sir Joseph Whitworth

Oh dear. I hate reasoning by analogy. It has never done anything for
me. I always wonder what parts are important and what parts are not.

stadnardised screw
threads. No longer did you need the matching nut for a bolt - all
bolts and nuts would match. Superficially that might seem a small
change. In fact it was one of the seminal events of the Industrial
Revolution.

And there is why I can't get one with it. Whitworth standardised the
thread profile but not the size. Different BSW sizes do *not* match.
Even C does better than that -- the different sizes can be assign and
converted, often without any problems at all.

Whitworth sizing was very important, but why was it extended with
extra profiles? Because the BSW profile does not work equally well
for all materials in all situations.[1]

So from this analogy I conclude that C's plethora of integer sizes is
already better than the Whitworth ideal (there are fewer of them and
the sizes are all compatible for assignment and comparison, whereas
different BSW thread do not "match" in any useful way at all[2]) and
that we should expect to introduce more, even less compatible, integer
types in future C to handle new, as yet unforeseen situations.

I don't for a moment believe what either of us thinks we can draw from
this analogy to an engineering standard -- so don't take this as a
counter argument. It is, like yours, a non-argument.[3]

Standardising on 64 bit integers will have a similar effect on the
productivity of C programmers.

I don't see the problem holding back the C programmers, and I can only
image that you have no evidence that it is really there or you would
be pointing to it rather than drawing analogies.

[1] The wide pitch makes BSW threads more prone to vibration. A
narrow pitch was required to cope well with modern mechanical
situations (in particular the "new" automotive industry).

[2] The value of the standardisation was that it no longer mattered
who you bought a 1/4" nut from. It did not mean that the different
nut sizes matched.

[3] Analogies can, sometimes, clarify an confused situation, but they
rarely help to persuade.

--
Ben.

Jul 17 '07 #34

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

>
Oh dear. I hate reasoning by analogy. It has never done anything for
me. I always wonder what parts are important and what parts are not.

And there is why I can't get one with it. Whitworth standardised the
thread profile but not the size. Different BSW sizes do *not* match.
Even C does better than that -- the different sizes can be assign and
converted, often without any problems at all.

Engineering is psychological as well as physical. When you are dealing with
human social beahviour, you don't get exactly the same situation twice.
For instance the Dutch tulip mania and the dot com bubble had some
similarities, but one wasn't just an exact replay of the other. Tulip mania
was confined to Holland whilst dot coms were international, for instance.
However the general rule that stocks can be wildly overbid still holds.

Similarly C standards and bolt standards have their differences. However it
obvious that C has too many integer types; short, int, long, long long, in
signed and unsigned, size_t and ptrdiff_t. That's ten standards for
representing an integer. We also know that standardisation tends to work.

You can't just argue by analogy, of course, but don't ignore the lessons of
history.

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

Jul 17 '07 #35

Keith Thompson

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

Similarly C standards and bolt standards have their
differences. However it obvious that C has too many integer types;
short, int, long, long long, in signed and unsigned, size_t and
ptrdiff_t.

[...]

It's obvious only to you.

--
Keith Thompson (The_Other_Keith) ks***@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"

Jul 17 '07 #36

"Malcolm McLean" <re*******@btinternet.comwrites:

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...
>>
Oh dear. I hate reasoning by analogy. It has never done anything for
me. I always wonder what parts are important and what parts are not.

And there is why I can't get one with it. Whitworth standardised the
thread profile but not the size. Different BSW sizes do *not* match.
Even C does better than that -- the different sizes can be assign and
converted, often without any problems at all.

Engineering is psychological as well as physical. When you are dealing
with human social beahviour, you don't get exactly the same situation
twice.
For instance the Dutch tulip mania and the dot com bubble had some
similarities,

More analogies. I'd rather see a C program that is hard to write
unless "int is 64 bits on 64 bit processors" (if that remains your now
rather narrow clam). A study showing what effect your proposed
changes might have on existing code bases (e.g. Linux, FreeBSD,
openSSL...) on 64 bit machines would also do more good than an appeal
to Whitworth thread sizing.

However it obvious that C has too many integer types;

Ah. If that means it is not debatable, then I have nothing more to
add.

--
Ben.

Jul 18 '07 #37

"Eric Sosman" <Er*********@sun.comwrote in message

>
First: Functions do not "talk to each other" through
integers alone. (If you doubt this, please explain how
strstr() communicates with its caller.) Second: Even if
integers were the official Esperanto of functiondom, why
should the language have only one word?

Take this:
void getcursor(unsigned char *x, unsigned short *y)

Here we are specifying that caller and callee shall communicate with each
other using a certain standard for specifying integer, namely the C short
representation. If caller passes the address of an int the compiler ought to
complain. More subtly, if he passes the address of a sint16 then he is also
committing an error.

There is no reason for using different representations of integers other
than machine efficiency. They are all just whole numbers. However on a 64
bit machine, 64 bit integers are efficient.

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

Jul 18 '07 #38

Eric Sosman

Malcolm McLean wrote On 07/18/07 17:02,:

"Eric Sosman" <Er*********@sun.comwrote in message

>>First: Functions do not "talk to each other" through
integers alone. (If you doubt this, please explain how
strstr() communicates with its caller.) Second: Even if
integers were the official Esperanto of functiondom, why
should the language have only one word?

Take this:

Why not the explanation of how strstr() and its caller
"talk to" each other via integers? Do you find the answer
an Inconvenient Truth?

void getcursor(unsigned char *x, unsigned short *y)

Here we are specifying that caller and callee shall communicate with each
other using a certain standard for specifying integer, namely the C short
representation. If caller passes the address of an int the compiler ought to
complain. More subtly, if he passes the address of a sint16 then he is also
committing an error.

The compiler *will* complain, in both cases, assuming
a prototype is in scope at the point of the call.

There is no reason for using different representations of integers other
than machine efficiency. They are all just whole numbers. However on a 64
bit machine, 64 bit integers are efficient.

One of the biggest problems in modern machine design
is dealing with the fact that the CPU reads and writes data
much faster than the memory can deliver and absorb it. Even
with multiple levels of very expensive cache to buffer the
speed mismatch, a CPU running at "100% utilization" is often
spending more than half its cycles in wait state, just idling
while the memory system trudges slowly along.

Using 16-bit shorts instead of your 64-bit whatevers, I
can get four times as many numbers to and from memory per
cache transaction. Between memory stalls, my CPU executes
four times as many instructions as yours -- or to turn it
around, my CPU can get through a bazillion computations with
one-quarter the number of memory stalls yours will incur.

... and you claim your CPU is running "efficiently?"

Real-world example: I'm transcribing some of my ancient
LP vinyl records onto CD via my home computer's sound card.
The CD recording format specifies 16-bit samples, and that's
what the sound card delivers, at 44100 samples per second
for each of two stereo channels. One side of an LP runs
about forty minutes, so my sound card produces about 400MB
per side. I've got 1.5GB of RAM, so even with Microbloat
and lots of other goo in the system there's still plenty of
room to soak up the data.

But with your "efficiency" ideas, I'd have 1600MB to
deal with instead. Not too terrible, because the data rate
of 40MB/s is probably something my disk can handle -- it'd
be nicer if I only had to worry about 10MB/s, but Malcolm
says it's better to spend the extra 30MB/s to make sure I've
got plenty of copies of the sign bits.

... and you claim this is "efficient?"

Then comes the editing, cleanup, track separation, and
so on, where the recorded data gets read in and massaged by
software. Instead of a sound file that fits entirely in
memory, I've got a file that cannot be processed without
going back and forth to the page device all the time. Now
instead of waiting (say) 200ns to get data from RAM, my
CPU is waiting (say) 10ms to get it from disk -- a small
matter of fifty thousand times longer.

... and you claim this is "efficient?"

Dogma has overtaken reason.

--
Er*********@sun.com

Jul 18 '07 #39

Richard

"Malcolm McLean" <re*******@btinternet.comwrites:

"Eric Sosman" <Er*********@sun.comwrote in message
>>
First: Functions do not "talk to each other" through
integers alone. (If you doubt this, please explain how
strstr() communicates with its caller.) Second: Even if
integers were the official Esperanto of functiondom, why
should the language have only one word?

Take this:
void getcursor(unsigned char *x, unsigned short *y)

Here we are specifying that caller and callee shall communicate with
each other using a certain standard for specifying integer, namely the
C short representation. If caller passes the address of an int the
compiler ought to complain. More subtly, if he passes the address of a
sint16 then he is also committing an error.

There is no reason for using different representations of integers
other than machine efficiency. They are all just whole
numbers. However on a 64 bit machine, 64 bit integers are efficient.

Different representations are used, if for nothing else, to aid
readability and mimic stronger typing.

In addition, when you have a certain "type" represented by "int" then to
give it its own "define" or typedef greatly simplifies things later if
and when you wish to change that particular type (e.g move to a long or
even a struct).

There is even the issue of context help. What IS a variable? One hot key
later the "type" (e.g GTK_SCREENCOORD) takes you to a detailed
explanation of the variable usage you are likely to encounter.

Jul 18 '07 #40

Richard Bos

"Malcolm McLean" <re*******@btinternet.comwrote:

"Eric Sosman" <Er*********@sun.comwrote in message

First: Functions do not "talk to each other" through
integers alone. (If you doubt this, please explain how
strstr() communicates with its caller.) Second: Even if
integers were the official Esperanto of functiondom, why
should the language have only one word?
Take this:
void getcursor(unsigned char *x, unsigned short *y)

I'd rather not. That is a wrongly designed interface. No wonder you're
scared of types, if this is how you habitually abuse them.

Here we are specifying that caller and callee shall communicate with each
other using a certain standard for specifying integer, namely the C short
representation. If caller passes the address of an int the compiler ought to
complain. More subtly, if he passes the address of a sint16 then he is also
committing an error.

There is no such thing as a sint16, so yes, passing that would be wrong.

There is no reason for using different representations of integers other
than machine efficiency.

Wrong _again_.

They are all just whole numbers. However on a 64
bit machine, 64 bit integers are efficient.

And we all have 64 bit machines, right? Guess what: wrong.

As long as you keep approaching C as if it were badly spelled BASIC, you
will never cure yourself of your polyintegrophobia.

Richard

Jul 19 '07 #41

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:46****************@news.xs4all.nl...

>They are all just whole numbers. However on a 64
bit machine, 64 bit integers are efficient.

And we all have 64 bit machines, right? Guess what: wrong.

The campaign for 64 bit ints campaigns for 64 bit ints on 64 bit machines,
maintaining the convention that int is the natural integer type for the
platform. On 32 bit machines it is accepted that int should be 32 bits, just
as it should be 16 bits on small machines with 16 bit registers.

The idea is that an integer can be used to index any array. (It is not quite
true because an array of chars that fills 2^63 + 1 bytes cannot be so
indexed, but that exception we will tolerate).
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jul 19 '07 #42

santosh

On Friday 20 Jul 2007 1:57 am, Malcolm McLean
<re*******@btinternet.comwrote in message
<oe******************************@bt.com>:

>
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:46****************@news.xs4all.nl...

>>They are all just whole numbers. However on a 64
bit machine, 64 bit integers are efficient.

And we all have 64 bit machines, right? Guess what: wrong.

The campaign for 64 bit ints campaigns for 64 bit ints on 64 bit
machines, maintaining the convention that int is the natural
integer type for the platform. On 32 bit machines it is accepted
that int should be 32 bits, just as it should be 16 bits on small
machines with 16 bit registers.

If you don't like abstract types, why not program in assembler? C is
what it is, and it's not going to change anytime soon.

I don't understand what exactly you are "campaigning" for: int to be
the only integer type in C, or for 64 bit platforms to become
mainstream?

Both are quite narrow-minded wishes. Different types exist because
they serve a felt need, as do different processors.

Jul 19 '07 #43

Malcolm McLean wrote, On 19/07/07 21:27:

>
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:46****************@news.xs4all.nl...

>>They are all just whole numbers. However on a 64
bit machine, 64 bit integers are efficient.

And we all have 64 bit machines, right? Guess what: wrong.

The campaign for 64 bit ints campaigns for 64 bit ints on 64 bit
machines, maintaining the convention that int is the natural integer
type for the platform. On 32 bit machines it is accepted that int should
be 32 bits, just as it should be 16 bits on small machines with 16 bit
registers.

Well, a small chip manufacturer called Intel seem to have different
opinion. http://download.intel.com/design/Ita...s/24535803.pdf
I'm a bit more inclined to trust their opinion than yours, since I
suspect they know a bit more about how to get the best out of processors
than you do.

The idea is that an integer can be used to index any array. (It is not
quite true because an array of chars that fills 2^63 + 1 bytes cannot be
so indexed, but that exception we will tolerate).

You've got an integer type for that already in C, it is called size_t.
Personally, I don't find 6 character names to be too long.
--
Flash Gordon

Jul 19 '07 #44

santosh

On Friday 20 Jul 2007 2:53 am, Eric Sosman <Er*********@sun.com>
wrote in message <1184880234.495526@news1nwk>:

<snip>

It takes me -- well, "more than ten minutes" to earn $240, [ ... ]

You're working too hard then! :)

Jul 19 '07 #45

"santosh" <sa*********@gmail.comwrote

>
I don't understand what exactly you are "campaigning" for: int to be
the only integer type in C, or for 64 bit platforms to become
mainstream?

The campaign is for int to be 64 bits on 64 bit machines.
There are reasons for this, one of which is that, at some future date, it
will enable us to simplify the language, particularly by removing size_t.

The campaign for 64 bits is important because 64 bit architectures are going
to come into common use in the near future. Whilst I welcome the end of the
2GB limit on memory, I am not trying to advocate use of 64 bit processors
where 32 bit processors would be adequate.

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

Jul 19 '07 #46

Ben Pfaff

"Malcolm McLean" <re*******@btinternet.comwrites:

The campaign for 64 bits is important because 64 bit architectures are
going to come into common use in the near future. Whilst I welcome the
end of the 2GB limit on memory, I am not trying to advocate use of 64
bit processors where 32 bit processors would be adequate.

Sounds like it should be named the "Campaign for 64 bits where 64
bits is due".
--
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield

Jul 19 '07 #47