Re: Array Size
On Thursday, July 4, 2013 8:12:46 AM UTC+1, David Brown wrote:
On 03/07/13 19:55, James Kanze wrote:
On Tuesday, 2 July 2013 22:10:28 UTC+1, David Brown wrote:
On 02/07/13 19:07, James Kanze wrote:
On Monday, 1 July 2013 15:18:01 UTC+1, David Brown wrote:
On 01/07/13 14:07, James Kanze wrote:
On Friday, 28 June 2013 19:50:30 UTC+1, David Brown wrote:
On 28/06/13 16:12, Scott Lurndal wrote:
Incidentally, what do you think is surprising about the semantics of
unsigned arithmetic in C? It has clear overflow semantics - unlike
signed integers, whose overflow semantics are undefined (and yet in any
real-world system /are/ well-defined unless the compiler optimises on
the assumption that they are undefined).
The fact that a - b is never negative, even if b > a.
That is not unexpected or surprising. When you do arithmetic on
unsigned numbers, you know you cannot subtract a bigger one from a
smaller one.
Exactly. That's precisely why you don't use unsigned numbers
for arithmetic values.
How is that different from saying that you should not use "int", because
you can't divide?
The difference is that I don't have to divide. If I have to
divide, I don't use int.
Or that you should not use "int" because if it is
only 16-bit, then adding 20,000 to 30,000 gives you a negative number
(or formats your hard disk, if you believe the rumours...) ?
The overflow issue is a red herring. I validate my input
upstream, so that I know overflow can't occur.
"Unsigned" integer types model unsigned integers, within limitations of
the machine. "Signed" integer types model signed integers, within the
limitations of the machine. There is /no/ problem here.
There is no such thing as an "unsigned integer" in math. One
would have liked for "unsigned" to model natural numbers, but
when I subtract two natural numbers, I get an integer; when
I compare a natural number with an integer, the natural number
converts to an integer. (That's actually what happened in the
earliest C---if you compared a signed and an unsigned, signed
comparison was used. For I don't know what reasons, the C
committee changed that, *and* added the modulo semantics.)
In the /real/ world, unsigned values are vastly more common than signed
ones.
I know. But in the real world, it is frequent to take the
difference between these numbers, and that difference will be
signed. In the real world, we use value preserving semantics.
[...]
In small embedded systems,
Other rules hold. I'm aware of this. (Back in the old days,
I did a lot of embedded systems on 8080 and 8051. When you only
have 128 bytes of RAM, other rules apply.)
[...]
And the simplest and cleanest way to avoid it is to not use
unsigned numbers for arithmetic values.
Just like the simplest and cleanest way to avoid division "surprises" is
not to use integers for arithmetic values.
Alternatively, you could try understanding what you are doing and
writing your code appropriately.
Understanding what I'm doing means that I don't use integers
when I'm going to divide. (There's even an argument for
preferring unsigned when you're going to divide. After all,
until C++11, the results of division with signed integers was
implementation defined.)
[...]
The set of integers is closed under subtraction. The set of
natural numbers isn't.
So what? What is your big problem about this?
C "int" types are not closed under subtraction or addition - yet you
want to use them. They are only closed if you make sure you don't
overflow or underflow.
The overflow issue is a red herring. You have to deal with it
with *all* machine types (except bool). It's an automatism to
verify input, based on what you are going to do with it, so that
overflow won't occur. (Of course, we'd like the program to
crash if it does, because we've violated our own
pre-conditions.)
I can see that would be a problem - /if/ I thought for a second that
finding the absolute difference between two indexes was so common for
that to be a problem.
In the work I do, it's not that rare (although we usually know
up front which index is larger). We also take the difference of
a lot of other thing that can never be negative. It's a general
principle.
So if I were writing a program that happened to do such
operations a lot, I would probably use signed integers for
such values. I certainly use signed integers in cases when
things can be negative, or where it makes the calculations
easier to get correct.
Another frequent use I've seen is to use -1 as a sentinal or
error value, for values which cannot otherwise be negative.
I'm not sure that that's a good practice, however, so I won't
use it as an argument for signed.
The C/C++ standards are of two minds about this. If you
subtract two pointers (or two iterators), the result *is*
a signed type (ptrdiff). If you're using idiomatic C++ (at
least on a general purpose machine---I can see where embedded
systems might be different), then if you want the index of an
entry in a vector, you'll do something like:
auto i = std::find( v.begin(), v.end(), target) - v.begin();
And i will be signed. (This is probably how I get most of my
indices anyway. With std::find, std::lower_bound, etc.)
In embedded code, pointers are much rarer - and in safe and reliable
code, array indexes are often much preferred over pointers because it is
easier to be sure that you are in the right place. And while C++ can
add many good things to small system programming, the STL is very rarely
appropriate. (I seldom use anything much from the C standard libraries
either.)
In embedded code, I wouldn't either. There are some nice things
in the standard library, but it certainly isn't designed for
minimal memory use.
When I worked on small embedded systems, I used unsigned types
exclusively. That was before C++, or even C (at least as far as
I was concerned), and the language I was using didn't even have
signed types. But for what I did in those systems, it wasn't an
issue. For larger general purpose systems, the issues are
different.
--
James