size_t problems

[Richard]

[snips]

What you not uncommonly find is that the actual processing that the app
performs is trivial - maybe it adds a few columns of numbers together and
produces a report.

Excuse?

Right now I'm working on a chess app; virtually all the code is
computational, with nigh-on nil for user interaction.

Recently I've written reporting apps - log processing, for example - which
read and process gigabytes of data, then produce web pages delineating
the results. No user interaction at all.

In fact, in all the coding I've ever done, the vast majority of it was
code to actually _do_ things, which means the code for processing
outweighs the code for interaction by a very large margin.

If you constrain yourself to nothing but toy programs, you'll get a toy
program view of the universe. We don't constrain ourselves this way; we
actually work on programs with some meat to them.

Who is "we"? Are you talking of you and your buddies at work, or for you
and the other posters here? There are zillions of C apps, you are
probably using one now, where the processing is indeed trivial compared
to wait time.

And waiting for UI, doesn't in any way mean that the program has no
"meat on its bones". Some user driven apps are by far the most
complicated needing complex graphics, sound and process handling.

Frankly, I think you are becoming rather boring with your increasingly
superior notions about what constitutes a "real program". Report
generation programs tend to be bog standard, tedious coding
exercises. They are as "toy like" as any others you might care to
mention. In fact my first *ever* commercial apps were just that - mind
numbingly boring C coding for back office reports for huge retails
stores. Nothing big or clever in them I am afraid.

 

[Tor Rustad]

Because an idiot programmer could write unsigned i;
for (i--; i >= 0; i--) and disasters would happen.

Put me in idiot club then. :-( Here, is the code snippet of a bug I
wrote today:

size_t i, j, k;

[...]

for (i=0, k=1; i<iso->field[P1_BITMAPS].length; i++)
{
for (j=7; j>=0; j--,k++)
{
if ( (bitmap >> j) & 1 )
{
has_field[k] = TRUE;
}
else
{
has_field[k] = FALSE;
}

}
}

now the code has

int i, j, k;

while "iso->field[P1_BITMAPS].length" still has size_t type.

 

[Kelsey Bjarnason]

[snips]

Who is "we"?

Based on some 20 years' coding and examining the code of others, I'd say
"most programmers".

and the other posters here? There are zillions of C apps, you are
probably using one now, where the processing is indeed trivial compared
to wait time.

Where did wait time come into the question? The discussion was about
processing done by the app, as contrasted to the UI for the app - not a
thing about wait times. Sorry, did I miss that in Malcolm's comments?

 

[jacob navia]

Are you under the impression that posting to comp.std.c constitutes
a formal presentation to the committee?

comp.std.c has no official association with the committee. It's just
a newsgroup that discusses the C standard. Some, but by no means all,
committee members hang out there, but they do so as individuals. You
can post anything you like there, as long as it's topical.

In other words, the way to "discuss it informally among interested
people" is *precisely* to post to comp.std.c.

If you want to present something to the committe, you need to talk to
your national body. I don't know what the procedure for that would
be, but I'm sure you can find out if you're sufficiently interested.

Mostly, that group has no developers, just language lawyers, people
that write compilers, etc, and have very specific questions about
paragraph xxx of the standard ...

Some discussions are possible. For instance when Mr Heathfield mentioned
in one of those discussions that he missed operator overloading I tried
to argument my position and sent a lengthy message explaining why
this would improve C.

The answer was a boatload of insults from Mr Heathfield at such a level
of bad taste that he killed the discussion. Other people answered of
course, why he insults around like that but the technical discussion
was killed, he won.

The problem with comp.std.c is that many people there are the same
"regulars" here, so I do not see much difference actually.

jacob

P.S. you know that. You read that group.

 

[Flash Gordon]

jacob navia wrote, On 04/09/07 19:54:

The problem with comp.std.c is that many people there are the same
"regulars" here, so I do not see much difference actually.

If there is not much difference then why not at least remove one reason
for people to complain against you by posting suggestions for changes to
C there instead of here.

 

[Malcolm McLean]

[snips]
Where did wait time come into the question? The discussion was about
processing done by the app, as contrasted to the UI for the app - not a
thing about wait times. Sorry, did I miss that in Malcolm's comments?

That's a slightly different issue. Run time is not unrelated to the
complexity of the code doing the processing, but it is not the same thing at
all. Code can be very hard to write yet execute in under just noticeable
time. Alternatively it can be very simple but soak up as much processing
power as you can throw at it.

However the majority of desktop apps do fairly trivial processing in both
senses. The functions are not mathematically complicated in any way, and
they don't take much time to execute. When I say "the majority" obviously
there are exceptions. A chess program that would beat Kasparov is one of
them.

 

[Malcolm McLean]

set to 9 or 10?

You're allowed 32 767 bytes in automatic memory, minimum. However if the
compiler writer has misread the campaign for 64 bit ints as the "campaign
for 64 byte ints", which is possible, even 9 bits will break.

 

[Malcolm McLean]

The "natural size" for int on most common 64 bit systems is 32 bits.
Unless you pick a specific definition of "natural" that excludes code
size and performance.

"natural" is the size needed for an arbitrary array index, because that is
what ints are mainly used for.

 

[Malcolm McLean]

Why should I waste 64 bits to store a flag variable, a value which
can either be a character or EOF, or an enumeration constant, or
the return type of main(), or ...

The standards benefit. If every nut fits every bolt, productivity is
massively increased. Of course every individual engineer would rather have
nuts and bolts of the particular size that suit the problem he is working
on, oh and the optimal thread pitch as well. The benefits only come when
almost everyone is using the same nut and the same bolt, and they are much
greater than most people would imagine from intuition.

 

[Malcolm McLean]

Notice he always avoids responding when these are mentioned. This tends
to the the usual behavior of a troll.

I read the document. It is nto much that it is wrong as that doesn't have
much to say about my issues. It focuses on the needs of the platform and the
compiler writers, whilst I focus on the needs of the programmer.

 

[Flash Gordon]

Malcolm McLean wrote, On 04/09/07 21:44:

The standards benefit. If every nut fits every bolt, productivity is
massively increased. Of course every individual engineer would rather
have nuts and bolts of the particular size that suit the problem he is
working on, oh and the optimal thread pitch as well. The benefits only
come when almost everyone is using the same nut and the same bolt, and
they are much greater than most people would imagine from intuition.

As previously pointed out to you and ignored on several occasions, nuts
and bolts come in LOTS of different sizes. The nuts and bolts used to
hold the engine in your car would not fit in my PDA, the nuts and bolts
in my PDA would not be able to hold your cars engine in place.

 

[Flash Gordon]

Malcolm McLean wrote, On 04/09/07 21:46:

I read the document. It is nto much that it is wrong as that doesn't
have much to say about my issues. It focuses on the needs of the
platform and the compiler writers, whilst I focus on the needs of the
programmer.

A sweeping statement like that does not address the points raised in the
documents as well as being wrong. In any case, haven't you noticed that
based on the only sample available programmers need to NOT have 64 bit
int forced on them. As far as I am aware you are the only person who
does programming that actually wants it.

 

[Kelsey Bjarnason]

[snips]

Mostly, that group has no developers, just language lawyers, people
that write compilers

Ah, so people who write compilers aren't developers, they're... plumbers?

 

[Kelsey Bjarnason]

Here it is:

Hmm. An article which is not a charter - snipped.

Sorry, you said you were going to post the charter, which doesn't exist,
for the group; could you do so now?

 

[Ian Collins]

"natural" is the size needed for an arbitrary array index, because that
is what ints are mainly used for.

Not in my world.

 

[Flash Gordon]

Malcolm McLean wrote, On 04/09/07 21:39:

"natural" is the size needed for an arbitrary array index,

No, or we would have had lots of compilers for 16 bit processors with
between 20 and 32 bit ints. Highly inefficient.

because that
is what ints are mainly used for.

Something you keep asserting even though everyone else who expresses an
opinion disagrees and without suitable evidence to back up you claim.
Repeatedly asserting what people believe to be a fallacy and using it as
an argument for doing something that people believe is the wrong thing
to do is unlikely to bring anyone round to your way of thinking.

 

[Ian Collins]

I read the document. It is nto much that it is wrong as that doesn't
have much to say about my issues. It focuses on the needs of the
platform and the compiler writers, whilst I focus on the needs of the
programmer.

Which one? http://www.unix.org/version2/whatsnew/lp64_wp.html is has a
heavy bias to the needs of the programmer.

 

[jacob navia]

[snips]

Mostly, that group has no developers, just language lawyers, people
that write compilers

Ah, so people who write compilers aren't developers, they're... plumbers?

But not!

I am not AGAINST them but I think language discussion should be done
with the developers, not specially with language lawyers and
specialists. Even if they are needed of course.

 

[Martin Wells]

Tor:

now the code has

int i, j, k;

You'd many other options. Here's just two:

Option A:

for (j = 7+1; j--; ++k)

Option B:

for (j = 7; j != -1; --j,++k)

Martin

 

[jacob navia]

Tor:



You'd many other options. Here's just two:

Option A:

for (j = 7+1; j--; ++k)

Option B:

for (j = 7; j != -1; --j,++k)

Martin

But that is not the point. The point is that you have to take care of
this stuff you see?

Many people (me included) would rather NOT TAKE CARE OF THIS STUFF!