Why no unsigned 32 bit integer?
Kevin W. Gale
I quick look through the FAQ did not reveal the answer.
So why does Delphi not support an unsigned 32 bit integer type.
This can really be a pain when dealing with existing APIs that
use unsigned integers.
Kevin
To reply to me remove the NOSPAM.
Encap Software
Kevin W. Gale wrote in message ...
>I quick look through the FAQ did not reveal the answer.
>
>So why does Delphi not support an unsigned 32 bit integer type.
>This can really be a pain when dealing with existing APIs that
>use unsigned integers.
>Actually a cardnal functions as both a 16 bit and 32 bit unsigned integer.
Borland refers to it as a "generic" type, and states:
"Applications should use the generic integer formats whenever possible,
since they generally result in the best performance for the underlying CPU
and operating system. The fundamental integer types should be used only when
the actual range and/or storage format matters to the application."
Dave Shapiro
Kevin W. Gale wrote:
> So why does Delphi not support an unsigned 32 bit integer type.
> This can really be a pain when dealing with existing APIs that
> use unsigned integers.
Cardinal is typed as an unsigned Integer: in Delphi 1, it's a Word
(2-byte unsigned), and in Delphi 2 and 3, it's a DWORD (4-byte
unsigned).
In Delphi 1, you can usually get away with using a LongInt. However, if
it's absolutely necessary, you can store it in a LongInt and cast to a
LongRec, which will give you access to the high and low words.
Dave
Lloyd Budd
Kevin W. Gale wrote:
>
> I quick look through the FAQ did not reveal the answer.
>
> This can really be a pain when dealing with existing APIs that
> use unsigned integers.
>
> To reply to me remove the NOSPAM.
It does and it is a: Comp
Nuff said,
Lloyd
darksoft
A Comp is a 64 bit signed integer, not a 32 bit unsigned integer. No version
of Delphi has a 32 bit unsigned integer, which is pretty pathetic. You'd think
that Borland would add the 32 bit unsigned integer in version 3, but they had
their head too far up M$ ass and instead implemented "packages" (another name
for the huge redistributable DLL's of VB) and ActiveEcchs shit.
If Boreland ever decides to implement a true 32 bit unsigned integer in Delphi
4, if it ever happens, maybe they'll have something worth upgrading from D2.
Lloyd Budd
Apologies, Borland Press must have thought they had an 32-unsigned int
when they wrote Delphi Developer's Guide because pg. 21 lists:
A Pascal-to-C-to-Visual-Basic type comparison.
Type of variable Pascal C(16-bit) Visual Basic
32-bit unsigned integer Comp unsigned long None
It doesn't and it isn't a: Comp
Lloyd
Martin Harvey
One reason for this is that unsigned 32 bit integers have a havit of
breaking the subtyping rules.
For more info on formal type theory, try posting something to
comp.compilers
MH.
Verily, "Kevin W. Gale" <k...@NOSPAM.world.std.com> spake thus:
darksoft
My copy has the pascal equivalent as None. Just looked it up. And for D2 and above, a comp is as follows from the D2 help file:
The Comp (computational) type holds only integral values within -2e63+1 to 2e63-1, which is approximately -9.2 * 10e18 to 9.2 * 10e18.
You read it wrong. It's a 64 bit signed integer.
Robert Lee
Kevin W. Gale wrote:
> I quick look through the FAQ did not reveal the answer.
>
> So why does Delphi not support an unsigned 32 bit integer type.
> This can really be a pain when dealing with existing APIs that
> use unsigned integers.
>
> Kevin
> To reply to me remove the NOSPAM.
If you are using 32bit delphi then Cardinal will work just fine. It has
a bit of a pecularity in that its "max" value is 2^31-1 and will
rollover to -2^31 if you add one to it, but this is just an illusion.
All operations performed on a cardinal type are of the unsigned
variety. As an example:
i:=high(i); // i = 2147483647 , $7FFFFFF
c:=high(c); // c = 2147483647, $7FFFFFF
i:=i+1; // i = -2147483648, $8000000
c:=c+1; // c = -2147483648, $8000000
i:=i div 2; // i:= -1073741824, $C0000000
c:=c div 2; // c:= 1073741824, $40000000
So while it may not alway look right, it will get the math right.
Bob Lee
Kevin W. Gale
Robert Lee wrote in message <34CF42F4...@nwu.edu>...
>
>If you are using 32bit delphi then Cardinal will work just fine. It has
>a bit of a pecularity in that its "max" value is 2^31-1 and will
>rollover to -2^31 if you add one to it, but this is just an illusion.
>All operations performed on a cardinal type are of the unsigned
>variety. As an example:
>
>i:=high(i); // i = 2147483647 , $7FFFFFF
>c:=high(c); // c = 2147483647, $7FFFFFF
>i:=i+1; // i = -2147483648, $8000000
>c:=c+1; // c = -2147483648, $8000000
>i:=i div 2; // i:= -1073741824, $C0000000
>c:=c div 2; // c:= 1073741824, $40000000
>
>So while it may not alway look right, it will get the math right.
>
I understand this and I use it in places. It is just very inconvenient.
I have to use some existing C APIs that use the full range of a
32 bit unsigned long. So I am always having to play games to
get the unsigned value of a signed type.
Simple code like
if a > b then
dosomething;
does not work because variables are signed instead of unsigned.
I can and do work around it in several ways.
I just do not understand why Dephi does not provide a 32 bit
unsigned type. After all it provides a 16 bit unsigned type.
I just want to know why.
Kevin
Robert Lee
Kevin W. Gale wrote:
> I just want to know why.
>
> Kevin
Those Why questions are black holes. Borland never publicly justifies why a
particular feature/structure is implemented the way it is. I suspect the
31bit limit may be related to Martin Harvey's post. The most encompassing
integer type is longint and all other integer types are derived as subtypes
from it. Thus all the integer types are compatible.
Of course, Borland saw fit to break this rule with pchar as it is at least
partially compatible with integers. Go Figure.
Bob Lee
Sundial Services
>I just do not understand why Dephi does not provide a 32 bit
>unsigned type. After all it provides a 16 bit unsigned type.
>I just want to know why.
So do I. :-/
Lloyd Budd
Yeah, okay, right.
It isn't worth argueing about, but no I didn't, I am staring at it right
now. I NOW know the Comp (computational) type holds only integral
values within -2e63+1 to 2e63-1, which is approximately -9.2 * 10e18 to
9.2 * 10e18. BUT like I said the copy of Delphi Developer's Guide that I
have copyright 1995 (first edition) lists it wrong.
Nuff said,
Lloyd.
Martin Harvey
Verily, Robert Lee <rh...@nwu.edu> spake thus:
>Those Why questions are black holes. Borland never publicly justifies why a
>particular feature/structure is implemented the way it is. I suspect the
>31bit limit may be related to Martin Harvey's post. The most encompassing
>integer type is longint and all other integer types are derived as subtypes
>from it. Thus all the integer types are compatible.
>Of course, Borland saw fit to break this rule with pchar as it is at least
>partially compatible with integers. Go Figure.
>Bob Lee
Bob,
Now you have reminded me slightly... I think it works like this:
All integer types are subranges of the basic enumeration longint. If
we make longint signed, then all the other types (both signed and
unsigned) shorter types are valid subranged of longint. However, if we
had longcard (32 bit unsigned) then the problem is that if we make it
the basic type, then signed types aren't a valid subrange, and if we
don't then it's going to be a supertype of our basic type.
This also (partly) explains why comp is not considered to be an
"ordinal" type .. ish ...
Martin H.
Robert Lee
Martin Harvey wrote:
> Bob,
>
> Now you have reminded me slightly... I think it works like this:
>
> All integer types are subranges of the basic enumeration longint. If
> we make longint signed, then all the other types (both signed and
> unsigned) shorter types are valid subranged of longint. However, if we
> had longcard (32 bit unsigned) then the problem is that if we make it
> the basic type, then signed types aren't a valid subrange, and if we
> don't then it's going to be a supertype of our basic type.
>
> This also (partly) explains why comp is not considered to be an
> "ordinal" type .. ish ...
>
> Martin H.
Yup, that's what I was thinking. The thing is that while this makes a lovely
paradigm, there's really no reason that signed and unsigned have to co-habitate.
In Bob's view of numbers, ordinal is unsigned and integer is signed. Besides,
signed and unsigned are already treated differently under the hood. (signed
variables generate arithmetic type assembler instructions while unsigned generate
logical).
We probably shouldn't beat on Borland for this because I believe they inherited
this from the "founding fathers" but I can't be sure because I don't have a pure
pascal text handy and haven't looked at one in years.
Bob Lee
Duncan Murdoch
>I just do not understand why Dephi does not provide a 32 bit
>unsigned type. After all it provides a 16 bit unsigned type.
>
>I just want to know why.
It's pretty simple. The rules of the language state that when you
have arithmetic operations involving two operands, the calculation is
carried out in an enclosing type, i.e. one which includes all the
values of both operands. Since you'll sometimes be adding signed and
unsigned values, this means the largest integer type in the language
has to be a signed type. No unsigned type will include the value -1,
for instance.
So to add a 32 bit unsigned type to the language, you'd need at least
a 33 bit signed type as well. That would have to be slow, since it
couldn't fit into a 32 bit register.
What's worse, it would even slow down programs that never used it
explicitly. I remember in 16 bit days noticing a big slowdown every
time I mixed word and integer in an expression; the problem was that
the compiler would calculate the value in a 32 bit longint, and then
shrink the answer down into whatever result type you specified.
So why doesn't C have this problem? It's a difference in philosophy.
In Pascal, "+" means addition in the standard mathematical sense. In
C it means addition in the sense of the computer where you do it. C
can afford to have expressions like "signed+unsigned" because it
doesn't care that the possible results won't fit into any type in the
language. Variables are just bit patterns, after all. In Pascal, that
would be unacceptable, because the variables hold integer values.
So why doesn't Borland just add a >32 bit integer type to the
language, e.g. by making Comp (a 64 bit signed integer) act as an
integer type instead of a real type?
I expect the efficiency concerns above are a part of it, but more
likely the main consideration is that it wouldn't stop the complaints:
people would just start wondering why there's no 64 bit unsigned type.
Besides, the number of cases where you actually need to treat a 32 bit
unsigned type as an integer, not just a bit pattern, are really
limited. You can roll your own comparisons and divisions for those
cases.
Duncan Murdoch
darksoft
In article <34d075a...@news.ccs.queensu.ca>, dmur...@pair.com (Duncan Murdoch) wrote:
>On Wed, 28 Jan 1998 15:22:59 GMT, "Kevin W. Gale"
><k...@NOSPAM.world.std.com> wrote:
>
>>I just do not understand why Dephi does not provide a 32 bit
>>unsigned type. After all it provides a 16 bit unsigned type.
>>
>>I just want to know why.
>
>So why doesn't Borland just add a >32 bit integer type to the
>language, e.g. by making Comp (a 64 bit signed integer) act as an
>integer type instead of a real type?
>
>I expect the efficiency concerns above are a part of it, but more
>likely the main consideration is that it wouldn't stop the complaints:
>people would just start wondering why there's no 64 bit unsigned type.
>Besides, the number of cases where you actually need to treat a 32 bit
>unsigned type as an integer, not just a bit pattern, are really
>limited. You can roll your own comparisons and divisions for those
>cases.
>
>Duncan Murdoch
How grossly inefficient can it possibly be in these days of Pentium II's?
Let's face it, Borland could choose to fix all this crap, but for some odd
reason don't . As for the cases when you'd need this being limited, ever hear
of image processing? Something I'll bet you have a program doing at least once
a day. It's done with integers, 32 bit UNSIGNED integers. Maybe that's why all
the decent programs are written with C, because Borland has too many people
making excuses for them refusing to upgrade the language to the 90's and
beyond.
There's no reason not to have 64 bit unsigned type as well, we're going to be
moving to a 64 bit OS soon. Or should Borland just wimper along dragging
behind M$ as they've always done?
Robert Lee
Duncan Murdoch wrote:
> It's pretty simple. The rules of the language state that when you
> have arithmetic operations involving two operands, the calculation is
> carried out in an enclosing type, i.e. one which includes all the
> values of both operands. Since you'll sometimes be adding signed and
> unsigned values, this means the largest integer type in the language
> has to be a signed type. No unsigned type will include the value -1,
> for instance.
>
What about PChar??? You can mix signed and unsigned here without
complaint.
Bob Lee
David Ullrich
darksoft wrote:
> [...]
> How grossly inefficient can it possibly be in these days of Pentium II's?
> Let's face it, Borland could choose to fix all this crap, but for some odd
> reason don't . As for the cases when you'd need this being limited, ever hear
> of image processing? Something I'll bet you have a program doing at least once
> a day. It's done with integers, 32 bit UNSIGNED integers.
Except in Delphi, where it's done with 32-bit SIGNED integers.
What's the difference? (Have you read any of the several posts explaining
that for most purposes you can just pretend longint is unsigned and
everything will be just fine? Do you have an EXAMPLE to the contrary?)
There's also various free unsigned-longint assembler packages
around, for example check Lischner's web page.
> Maybe that's why all
> the decent programs are written with C, because Borland has too many people
> making excuses for them refusing to upgrade the language to the 90's and
> beyond.
>
> There's no reason not to have 64 bit unsigned type as well, we're going to be
> moving to a 64 bit OS soon. Or should Borland just wimper along dragging
> behind M$ as they've always done?
--
David Ullrich
sig.txt not found
Duncan Murdoch
On Thu, 29 Jan 1998 16:14:50 GMT, dark...@gte.net (darksoft) wrote:
> As for the cases when you'd need this being limited, ever hear
>of image processing? Something I'll bet you have a program doing at least once
>a day. It's done with integers, 32 bit UNSIGNED integers.
As far as I know the image processing on my system uses at most 8 bits
for each colour component. I don't believe it ever does any
calculations that need a full 32 bits treated all as one unsigned
integer, rather than a concatenation of smaller ones.
Can you give me an example of the kind of calculation it would need to
do that wouldn't work with a signed 32 bit integer?
>>I expect the efficiency concerns above are a part of it, but more
>>likely the main consideration is that it wouldn't stop the complaints:
>>people would just start wondering why there's no 64 bit unsigned type.
>There's no reason not to have 64 bit unsigned type as well ....
See? I was right. Some people will always whine about the fact that
Pascal isn't C.
I don't really understand this: C has a lot of advantages over Pascal
if you're looking for a low level language that's not as hard to read
as assembler, so why not just use it? Nobody is telling you that you
have to write every part of every program in Delphi. Write your
graphics library in C if you want, and call it from Delphi. That's
what I do (except I get someone else to do the C part, and they
probably use assembler rather than C for a lot of it).
Duncan Murdoch
darksoft
In article <34D0DE...@math.okstate.edu>, David Ullrich <ull...@math.okstate.edu> wrote:
>darksoft wrote:
>> [...]
>> How grossly inefficient can it possibly be in these days of Pentium II's?
>> Let's face it, Borland could choose to fix all this crap, but for some odd
>> of image processing? Something I'll bet you have a program doing at least
> once
>> a day. It's done with integers, 32 bit UNSIGNED integers.
>
>What's the difference? (Have you read any of the several posts explaining
>that for most purposes you can just pretend longint is unsigned and
>everything will be just fine? Do you have an EXAMPLE to the contrary?)
>
> There's also various free unsigned-longint assembler packages
>around, for example check Lischner's web page.
That's just a ULONG assign to a signed 32 bit integer, not the real deal. Why
wait until half way thru a project to find out that it won't work? I mean,
shit, let's be real here. Pretending it's unsigned just don't cut it.
darksoft
In article <34d7cebf...@news.ccs.queensu.ca>, dmur...@pair.com (Duncan Murdoch) wrote:
>On Thu, 29 Jan 1998 16:14:50 GMT, dark...@gte.net (darksoft) wrote:
>>of image processing? Something I'll bet you have a program doing at least once
>
>>a day. It's done with integers, 32 bit UNSIGNED integers.
>
>for each colour component. I don't believe it ever does any
>calculations that need a full 32 bits treated all as one unsigned
>integer, rather than a concatenation of smaller ones.
So you work with a byte at a time? If you knew anything at all about image
processing in code, you wouldn't be making such sweeping ignorant statements.
Just because it's displayed with 8 bits per gun means jack.
>Can you give me an example of the kind of calculation it would need to
>do that wouldn't work with a signed 32 bit integer?
How about working all three color guns and an alpha channel during a
conversion? Like I said, if you knew anything about image processing, you
wouldn't have to ask.
>>>I expect the efficiency concerns above are a part of it, but more
>>>likely the main consideration is that it wouldn't stop the complaints:
>>>people would just start wondering why there's no 64 bit unsigned type.
>
>>There's no reason not to have 64 bit unsigned type as well ....
>
>See? I was right. Some people will always whine about the fact that
>Pascal isn't C.
No, just whining because Object Pascal is still stuck back in the stone age.
>I don't really understand this: C has a lot of advantages over Pascal
>if you're looking for a low level language that's not as hard to read
>as assembler, so why not just use it? Nobody is telling you that you
>have to write every part of every program in Delphi. Write your
>graphics library in C if you want, and call it from Delphi. That's
>what I do (except I get someone else to do the C part, and they
>probably use assembler rather than C for a lot of it).
>
>Duncan Murdoch
If I knew C, which I don't and I liked C, which I don't, I wouldn't be usnig
Delphi at all and we wouldn't be having this conversation. I just love people
like you. Instead of improving the language, you're all for keeping it in the
stone age and telling those who want improvemts to move to C. Fuck, I've never
seen such a bunch since my Amiga days! And Borland is Commodore all over
again!
Duncan Murdoch
On Thu, 29 Jan 1998 12:23:09 -0600, Robert Lee <rh...@nwu.edu> wrote:
>What about PChar??? You can mix signed and unsigned here without
>complaint.
I'm not saying there's any problem in the current language, there
isn't. You can mix signed and unsigned operations; the answer will be
calculated as though everything is converted to signed first.
The problem would come if there were a full 32 bit unsigned type.
Then it wouldn't be clear what you meant if you mixed it with a signed
type, because there would be no type that could hold both operands.
(Unless you added one ...)
I'm not sure what PChar has to do with anything. Could you give an
example of something involving PChar that seems to conflict with what
I was saying? As far as I remember, the only things you can do with
PChars is to add or subtract integers, they aren't a full integer
type. Addition and subtraction are the same signed or unsigned
anyway.
Duncan Murdoch
Robert Lee
Luke Webber wrote:
> I wasn't planning to jump into this one, but I'm afraid I just can't
> resist.
>
> As I see it, the real problem is that Borland are looking at this from the
> wrong direction. Instead of assuming that a mixed signed/unsigned
> operation should produce a signed result, why not assume that it's
> unsigned?
>
> For that matter, why not disallow mixed signed/unsigned operations
> entirely without a cast? It's really just a matter of making the
> programmer make up his/her mind about what type of result they want if
> their intention is unclear.
>
There you go. That's what I'm saying though I might be a bit more liberal than
required typecasting.
The only case that's really any different than the current situation is
longint:=longint operation Cardinal
where Cardinal is greater than 2 gig in which the conversion to longint
fails. But this is just a different kind of range error so it could be
handled just the same. Range Checking on: Get Runtime error. Range Checking
off: You get wierd results. Just like now with any other integer operation.
Bob Lee
Sundial Services
>>>I just love people
>>>like you. Instead of improving the language, you're all for keeping it in the
>>>stone age and telling those who want improvemts to move to C. Fuck, I've never
>>
>>>seen such a bunch since my Amiga days! And Borland is Commodore all over
>>>again!
>>
>>Hey, the feeling is mutual! I just love people who troll newsgroups
>>making claims but not backing them up when challenged, and do it all
>>in the most insulting way they can. It's even better when they do it
>>anonymously!
>I can't help it if you don't know anything about image processing. It's not
>something I'm willing to take the massive amount of time it would require to
>attempt to explain it to you either. I can be insulting if that's what you
>like. As far as anonymous, finger me.
>>Sorry, I won't be hooked again. You'll have to argue with someone
>>else.
>Or maybe just with someone with a clue.
tap... tap... tap... gentlebeings, pleuz...
we're all humans here. sad but true.
Luke Webber
I wasn't planning to jump into this one, but I'm afraid I just can't
resist.
As I see it, the real problem is that Borland are looking at this from the
wrong direction. Instead of assuming that a mixed signed/unsigned
operation should produce a signed result, why not assume that it's
unsigned?
For that matter, why not disallow mixed signed/unsigned operations
entirely without a cast? It's really just a matter of making the
programmer make up his/her mind about what type of result they want if
their intention is unclear.
dmur...@pair.com (Duncan Murdoch) writes:
>I'm not saying there's any problem in the current language, there
>isn't. You can mix signed and unsigned operations; the answer will be
>calculated as though everything is converted to signed first.
>The problem would come if there were a full 32 bit unsigned type.
>Then it wouldn't be clear what you meant if you mixed it with a signed
>type, because there would be no type that could hold both operands.
>(Unless you added one ...)
--
Luke Webber
* Note: The opinions expressed by Luke Webber are in no way supported *
* by his employers, Luke Webber Consulting Services *
Duncan Murdoch
On Thu, 29 Jan 1998 22:18:34 GMT, dark...@gte.net (darksoft) wrote:
>I just love people
>like you. Instead of improving the language, you're all for keeping it in the
>stone age and telling those who want improvemts to move to C. Fuck, I've never
>seen such a bunch since my Amiga days! And Borland is Commodore all over
>again!
Hey, the feeling is mutual! I just love people who troll newsgroups
making claims but not backing them up when challenged, and do it all
in the most insulting way they can. It's even better when they do it
anonymously!
Sorry, I won't be hooked again. You'll have to argue with someone
else.
Duncan Murdoch
darksoft
In article <34d422d3...@news.ccs.queensu.ca>, dmur...@pair.com (Duncan Murdoch) wrote:
>On Thu, 29 Jan 1998 22:18:34 GMT, dark...@gte.net (darksoft) wrote:
>
>>I just love people
>>like you. Instead of improving the language, you're all for keeping it in the
>>stone age and telling those who want improvemts to move to C. Fuck, I've never
>
>>seen such a bunch since my Amiga days! And Borland is Commodore all over
>>again!
>
>Hey, the feeling is mutual! I just love people who troll newsgroups
>making claims but not backing them up when challenged, and do it all
>in the most insulting way they can. It's even better when they do it
>anonymously!
I can't help it if you don't know anything about image processing. It's not
something I'm willing to take the massive amount of time it would require to
attempt to explain it to you either. I can be insulting if that's what you
like. As far as anonymous, finger me.
>Sorry, I won't be hooked again. You'll have to argue with someone
>else.
Or maybe just with someone with a clue.
Piotr Trzcionkowski
Tue, 27 Jan 1998 16:41:33 GMT, "Kevin W. Gale"
<k...@NOSPAM.world.std.com> napisał(a):
>I quick look through the FAQ did not reveal the answer.
>
>So why does Delphi not support an unsigned 32 bit integer type.
>This can really be a pain when dealing with existing APIs that
>use unsigned integers.
You can use standard signed long integer. All positive numbers have
the same contents and even operations with any positive and negative
is correct independent from it is signed or unsigned (numbers are
wraped). Only result you need show depends is signed or unsigned.
Probably this work can be doing through Format or wvsprintf functions.
Alexander Petrosyan (PAF)
Duncan Murdoch пишет в сообщении <34d075a...@news.ccs.queensu.ca> ...
>On Wed, 28 Jan 1998 15:22:59 GMT, "Kevin W. Gale"
><k...@NOSPAM.world.std.com> wrote:
>>I just do not understand why Dephi does not provide a 32 bit
>>unsigned type. After all it provides a 16 bit unsigned type.
I wondered about this thing in my local newsgroup without much interest,
would try asking here.
This declaration compiles/works find with D2, but dont pass D3 compiler with
'data type is bigger then 2GB'.
type
foo = array[LongBool] of bar
Why is that? I'd like to hear some opinions...
It seems completely strange for me, why breaking nice working thing...
--
Alexander Petrosyan (PAF), Moscow.
email: p...@i-connect.ru; p...@fbit.msk.su
home: http://www.i-connect.ru/~paf
Duncan Murdoch
On 29 Jan 1998 22:15:02 -0700, news-...@sundialservices.com (Sundial
Services) wrote:
>tap... tap... tap... gentlebeings, pleuz...
>we're all humans here. sad but true.
You're right, my reply was inappropriate. I've cancelled it.
Duncan Murdoch
Duncan Murdoch
On Thu, 29 Jan 1998 20:40:09 -0600, Robert Lee <rh...@nwu.edu> wrote:
>There you go. That's what I'm saying though I might be a bit more liberal than
>required typecasting.
>
>The only case that's really any different than the current situation is
>
>longint:=longint operation Cardinal
>
>where Cardinal is greater than 2 gig in which the conversion to longint
>fails. But this is just a different kind of range error so it could be
>handled just the same. Range Checking on: Get Runtime error. Range Checking
>off: You get wierd results. Just like now with any other integer operation.
It's not just arithmetic, it's also comparison. Let's say your
operation is ">". There are different machine instructions for signed
compares versus unsigned compares (JL etc versus JB etc). Which one
should be used? If it does an unsigned compare, it will say that "-1
> 0" is true, which is nonsense. If it does a signed compare, it will
say that "0 > $FFFFFFFF" which is also nonsense.
The solution is to promote both operands to a larger type (at least 33
bits) that can hold the sign and the full range of values, and then do
a signed compare. That's what happened in 16 bit days, signed and
unsigned 16 bit values were promoted to 32 bits for the mixed
operations.
So Borland could solve all the 32 bit problems by adding a 64 bit
integer, which wouldn't be a bad idea at all. But then exactly the
same problems would arise with 64 bit mixed signed and unsigned
operations.
Duncan Murdoch
Robert Lee
Your comparison case is just the same. if mixed types are presented the cardinal
must be typecast to longint. If its value is greater than 2 gig then you get a
range error. If not, everything's kosher.
We're just going round and round. It boils down to form over function. The
current situation makes for a nice diagram of ordinal types at the expense of true
32 bit unsigned values. This could be readily fixed but the view of ordinals would
be a bit less elegant.
Bob Lee
Ray Lischner
Using LongInt is usually adequate. For comparison and division, you
need extra help. Download the Unsigned unit from
http://www.tempest-sw.com/freeware/.
--
Ray Lischner (http://www.tempest-sw.com/)
Author of "Hidden Paths of Delphi 3: Experts, Wizards, and the Open Tools API"
Eric Blood
In article <34d8cd9b...@news.ccs.queensu.ca>,
dmur...@pair.com (Duncan Murdoch) wrote:
There is another solution. You leave the rule for integer operations
as you have stated it but you extend it slightly to say that if an
integer type which contains the range of both operands does not exist
then disallow the operation. This would mean that the language could
have a 32 bit unsigned integer but if you try to use it in any operation
with a signed integer of any type you would get a compile error. You
would still, of course, be able to typecast one or the other of the
operands if you really do want to perform the operation.
This rule would not be as simple and straight-forward as the current
rule but it would keep the basic principles that the results are
predictable and do not depend on the underlying machine architecture.
-----------------------------------------------------------------------------
Eric Blood
ebl...@xmission.com
David Ullrich
darksoft wrote:
> [...]
> > Except in Delphi, where it's done with 32-bit SIGNED integers.
> >What's the difference? (Have you read any of the several posts explaining
> >that for most purposes you can just pretend longint is unsigned and
> >everything will be just fine? Do you have an EXAMPLE to the contrary?)
> >
> > There's also various free unsigned-longint assembler packages
> >around, for example check Lischner's web page.
>
> That's just a ULONG assign to a signed 32 bit integer, not the real deal. Why
> wait until half way thru a project to find out that it won't work? I mean,
> shit, let's be real here. Pretending it's unsigned just don't cut it.
You're the guy who's being unreal. For the second time: What's
the EXAMPLE where it doesn't work? Exactly what goes wrong???
David Ullrich
darksoft wrote:
>
> In article <34d7cebf...@news.ccs.queensu.ca>, dmur...@pair.com (Duncan Murdoch) wrote:
> >On Thu, 29 Jan 1998 16:14:50 GMT, dark...@gte.net (darksoft) wrote:
> >> As for the cases when you'd need this being limited, ever hear
> >>of image processing? Something I'll bet you have a program doing at least once
> >
> >>a day. It's done with integers, 32 bit UNSIGNED integers.
> >
> >As far as I know the image processing on my system uses at most 8 bits
> >for each colour component. I don't believe it ever does any
> >calculations that need a full 32 bits treated all as one unsigned
> >integer, rather than a concatenation of smaller ones.
>
> So you work with a byte at a time? If you knew anything at all about image
> processing in code, you wouldn't be making such sweeping ignorant statements.
> Just because it's displayed with 8 bits per gun means jack.
>
> >Can you give me an example of the kind of calculation it would need to
> >do that wouldn't work with a signed 32 bit integer?
>
> How about working all three color guns and an alpha channel during a
> conversion?
Yes, how about that? When you're working with three color channels
and and alpha channel do you actually do arithmetic operations on the
whole thing at once - when you do your image processing you enjoy it when
the RGB channels bleed into the alpha channel?
Or do you process the four channels separately? (You think that
just because there's no DWORD type in Delphi you can't regard the
high byte as an unsigned byte or what? Selphi thinks the high bit is
a sign bit, and that makes it some magic bit that's not gonna work
for an alpha channel?)
> Like I said, if you knew anything about image processing, you
> wouldn't have to ask.
> [...]
> If I knew C, which I don't and I liked C, which I don't, I wouldn't be usnig
> Delphi at all and we wouldn't be having this conversation. I just love people
> like you. Instead of improving the language, you're all for keeping it in the
> stone age and telling those who want improvemts to move to C. Fuck, I've never
> seen such a bunch since my Amiga days! And Borland is Commodore all over
> again!
Lemme get this straight. You're an expert on image processing but you
don't know any C. You're a big enough expert on image processing to make
all this, um, fucking noise about how awful Delphi is because there's
no DWORDS so you can't do image processing. But you don't know any C.
What language DO you use for your image processing work? And what's
an EXAMPLE of some image-processing task that you want to do that's made
impossible or even more difficult by the fact that there's no unsigned
longint in Delphi? (Do you have any clue whatever?)
Martin Harvey
Verily, lu...@oberon.sub.net.au (Luke Webber) spake thus:
>I wasn't planning to jump into this one, but I'm afraid I just can't
>resist.
>As I see it, the real problem is that Borland are looking at this from the
>wrong direction. Instead of assuming that a mixed signed/unsigned
>operation should produce a signed result, why not assume that it's
>unsigned?
>For that matter, why not disallow mixed signed/unsigned operations
>entirely without a cast? It's really just a matter of making the
>programmer make up his/her mind about what type of result they want if
>their intention is unclear.
That was done in Modula-2. I found it a massive pain in the backside
on some occasions... you ended up with big arithmetic expressions with
loads of casts in the middle... made it really hard to read.
MH.
Martin Harvey
Verily, dmur...@pair.com (Duncan Murdoch) spake thus:
>Duncan Murdoch
Duncan,
Your first post about the reasoning behind not allowing unsigned
integers was correct and well thought through. Don't rise to the bait!
MH.
Martin Harvey
Verily, Robert Lee <rh...@nwu.edu> spake thus:
>Duncan Murdoch wrote:
>Bob Lee
Yes.... but that's a C idiom, which doesn't relate to the above
discussion.
MH.
darksoft
In article <34D233...@math.okstate.edu>, David Ullrich <ull...@math.okstate.edu> wrote:
>darksoft wrote:
>>
>> In article <34d7cebf...@news.ccs.queensu.ca>, dmur...@pair.com (Duncan
> Murdoch) wrote:
>> >On Thu, 29 Jan 1998 16:14:50 GMT, dark...@gte.net (darksoft) wrote:
>> >> As for the cases when you'd need this being limited, ever hear
>> >>of image processing? Something I'll bet you have a program doing at least
> once
>> >
>> >>a day. It's done with integers, 32 bit UNSIGNED integers.
>> >
>> >As far as I know the image processing on my system uses at most 8 bits
>> >for each colour component. I don't believe it ever does any
>> >calculations that need a full 32 bits treated all as one unsigned
>> >integer, rather than a concatenation of smaller ones.
>>
>> So you work with a byte at a time? If you knew anything at all about image
>> processing in code, you wouldn't be making such sweeping ignorant statements.
>> Just because it's displayed with 8 bits per gun means jack.
>>
>> >Can you give me an example of the kind of calculation it would need to
>> >do that wouldn't work with a signed 32 bit integer?
>>
>> How about working all three color guns and an alpha channel during a
>> conversion?
>
> Yes, how about that? When you're working with three color channels
>and and alpha channel do you actually do arithmetic operations on the
>whole thing at once - when you do your image processing you enjoy it when
>the RGB channels bleed into the alpha channel?
No, I suppose you could work with one byte at a time and be a total idiot.
> Or do you process the four channels separately? (You think that
>just because there's no DWORD type in Delphi you can't regard the
>high byte as an unsigned byte or what? Selphi thinks the high bit is
>a sign bit, and that makes it some magic bit that's not gonna work
>for an alpha channel?)
>
>> Like I said, if you knew anything about image processing, you
>> wouldn't have to ask.
>> [...]
>> If I knew C, which I don't and I liked C, which I don't, I wouldn't be usnig
>> Delphi at all and we wouldn't be having this conversation. I just love people
>> like you. Instead of improving the language, you're all for keeping it in the
>> stone age and telling those who want improvemts to move to C. Fuck, I've
> never
>> seen such a bunch since my Amiga days! And Borland is Commodore all over
>> again!
>
> Lemme get this straight. You're an expert on image processing but you
>don't know any C. You're a big enough expert on image processing to make
>all this, um, fucking noise about how awful Delphi is because there's
>no DWORDS so you can't do image processing. But you don't know any C.
Where the fuck does it say I have to know C to program anything to do with
image processing, genius? Who says I have to be an expert at anything to make
noise about Delphi not having an unsigned 32 bit integer? Who the fuck made
you the complaint department?
> What language DO you use for your image processing work? And what's
>an EXAMPLE of some image-processing task that you want to do that's made
>impossible or even more difficult by the fact that there's no unsigned
>longint in Delphi? (Do you have any clue whatever?)
Prior to Delphi it was in 68K assembly, which handily happens to have no
restriction on 32 bit integers. I don't have a handy example for you. Does
that automagically negate my need down the road for an unsigned 32 bit
integer?
Fuck off. If you don't care to see the language improved, fine. I don't happen
to take the sheep attitude you have and accept blindly what's been given out
with Delphi. Maybe I want it to have some things it should have fucking had
from the beginning. I just love this attitude that if it wasn't in there then
it shouldn't ever be in there. Maybe you're secretly M$ shills.
Robert Lee
Martin Harvey wrote:
It relates in the sense that Borland decided that functionality was more
important the keeping pointers all clean and pure. My argument, is exactly
the same. Think back to 16bit. The potential to have the offset part of a
pchar wrap around was very real, and yet Borland gave us the functionality
to add/subtract to a pointer with only a "user beware."
Borland could do something similar here. With range checking on any attempt
to cast an unsigned greater than 2 gig to a longint should just throw a
range error. Any operation involving mixed types require that all unsigned
values be cast to signed now, so it's not like I asking for a complete
redesign of arithmetic operations.
Finally, as noted previously, this problem is not going to go away. There
will always be a conflict at the largest sizes of signed and unsigned.
Actually, its worse than that. How many people are really going to need to
count to +/- 2^256? But there will always be a good deal of interest on the
unsigned side because unsigned values frequently have nothing to do with
counting. Rather, they are frequently more concerned with some form of bit
twiddling, and the more bits the merrier.
Bob Lee
Jeremy Collins
>No, I suppose you could work with one byte at a time and be a total idiot.
>
>> Or do you process the four channels separately? (You think that
>>just because there's no DWORD type in Delphi you can't regard the
>>high byte as an unsigned byte or what? Selphi thinks the high bit is
>>a sign bit, and that makes it some magic bit that's not gonna work
>>for an alpha channel?)
>> never
>>> seen such a bunch since my Amiga days! And Borland is Commodore all over
>>> again!
>>
>> Lemme get this straight. You're an expert on image processing but you
>>don't know any C. You're a big enough expert on image processing to make
>>all this, um, fucking noise about how awful Delphi is because there's
>>no DWORDS so you can't do image processing. But you don't know any C.
>
>Where the fuck does it say I have to know C to program anything to do with
>image processing, genius? Who says I have to be an expert at anything to make
>noise about Delphi not having an unsigned 32 bit integer? Who the fuck made
>you the complaint department?
>Fuck off. If you don't care to see the language improved, fine. I don't happen
>to take the sheep attitude you have and accept blindly what's been given out
>with Delphi. Maybe I want it to have some things it should have fucking had
>from the beginning. I just love this attitude that if it wasn't in there then
>it shouldn't ever be in there. Maybe you're secretly M$ shills.
<uk specific>
-dons curly haired wig & fake moustache
"Calm down, calm down"
</uk specific>
Come on guys, let's keep this polite, eh?
We all have varying areas of expertise and experience, or have you
forgotton what, to me, is the whole point of this newsgroup, namely
"between us, we know it all".
One thing is for sure - you're not going to improve a product or
change someone's mind by exchanging insults with a complete stranger
across an internet connection.
--
Jeremy Collins
Duncan Murdoch
On 30 Jan 1998 11:51:05 -0700, ebl...@xmission.com (Eric Blood) wrote:
>There is another solution. You leave the rule for integer operations
>as you have stated it but you extend it slightly to say that if an
>integer type which contains the range of both operands does not exist
>then disallow the operation.
Yes, that would be another solution. If they decided to call the new
unsigned type Cardinal, it would be some work fixing old code so it
would compile in the new more restrictive rules, but it could be done.
I'd rather have a 64 bit signed type and set Cardinal to a 63 bit
unsigned type, but probably there'd be people who would prefer your
solution.
Duncan Murdoch
AlanGLLoyd
>Fuck off. If you don't care to see the language improved, fine. I don't
>happen
>to take the sheep attitude you have and accept blindly what's been given out
>with Delphi. Maybe I want it to have some things it should have fucking had
>from the beginning. I just love this attitude that if it wasn't in there then
>
>it shouldn't ever be in there. Maybe you're secretly M$ shills.
>
>
Those with weak arguments resort to personal insults.
Those without argument skills resort to angry obscenity.
Let's keep to impersonal factual debate, not immature shouting.
In 3 years are we going to have to go through this shouting match about 64-bit
unsigned integers ? <g>
Alan Lloyd
alang...@aol.com
Duncan Murdoch
On Fri, 30 Jan 1998 21:19:03 -0600, Robert Lee <rh...@nwu.edu> wrote:
> But there will always be a good deal of interest on the
>unsigned side because unsigned values frequently have nothing to do with
>counting. Rather, they are frequently more concerned with some form of bit
>twiddling, and the more bits the merrier.
The real point is that for the purposes of bit twiddling, it makes no
difference whatsoever whether you use a signed or unsigned type. By
convention, C programmers normally use an unsigned type for this, but
you don't have to follow their conventions.
BTW, I still don't know what you meant when you brought up PChar.
Could you expand on that?
Duncan Murdoch
Stefan Hoffmeister
: Robert Lee <rh...@nwu.edu> wrote:
>Martin Harvey wrote:
>
>> Verily, Robert Lee <rh...@nwu.edu> spake thus:
>>
>> >Duncan Murdoch wrote:
>>
>> >What about PChar??? You can mix signed and unsigned here without
>> >complaint.
>>
>> Yes.... but that's a C idiom, which doesn't relate to the above
>> discussion.
>>
>> MH.
>
>It relates in the sense that Borland decided that functionality was more
>important the keeping pointers all clean and pure. My argument, is exactly
>the same. Think back to 16bit. The potential to have the offset part of a
>pchar wrap around was very real, and yet Borland gave us the functionality
>to add/subtract to a pointer with only a "user beware."
The only beware I remember was that the pointer be in the same
segment. This is an architectural restriction (Intel), not a compiler
issue (Borland).
Now that we have finally gotten rid of segments we can add/subtract
pointers without caveat.
--
mailto:Stefan.Hoffmeister (at) Uni-Passau.de
http://kakadu.rz.uni-passau.de/~w4hoff01/
DIR: Delphi FAQs, KBs, docs
PGP public key at homepage
Stefan Hoffmeister
: dark...@gte.net (darksoft) wrote:
>> What language DO you use for your image processing work? And what's
>>an EXAMPLE of some image-processing task that you want to do that's made
>>impossible or even more difficult by the fact that there's no unsigned
>>longint in Delphi? (Do you have any clue whatever?)
>
>Prior to Delphi it was in 68K assembly, which handily happens to have no
>restriction on 32 bit integers. I don't have a handy example for you. Does
>that automagically negate my need down the road for an unsigned 32 bit
>integer?
No. But why don't you do it in Intel 386 assembler then? Or, even
better, MMX specific code? THAT should get you some nice performance.
I am certain that a programming wizard like you can just use longint
as a 32bit integer (be it signed or not) - as has been suggested.
[Obscenities cut]
Welcome to my kill filter. 30 days to cool down.
PS: I am not opposed to improvements / changes.
Rudy Velthuis
darksoft wrote...
>No, I suppose you could work with one byte at a time and be a total
idiot.
>
>> Or do you process the four channels separately? (You think
that
>>just because there's no DWORD type in Delphi you can't regard the
>>high byte as an unsigned byte or what? Selphi thinks the high bit is
>>a sign bit, and that makes it some magic bit that's not gonna work
>>for an alpha channel?)
>>
>>> Like I said, if you knew anything about image processing, you
>>> wouldn't have to ask.
>>> [...]
>>> If I knew C, which I don't and I liked C, which I don't, I
wouldn't be usnig
>>> Delphi at all and we wouldn't be having this conversation. I just
love people
>>> like you. Instead of improving the language, you're all for
keeping it in the
>>> stone age and telling those who want improvemts to move to C.
Fuck, I've
>> never
>>> seen such a bunch since my Amiga days! And Borland is Commodore
all over
>>> again!
>>
>> Lemme get this straight. You're an expert on image
processing but you
>>don't know any C. You're a big enough expert on image processing to
make
>>all this, um, fucking noise about how awful Delphi is because
there's
>>no DWORDS so you can't do image processing. But you don't know any
C.
>
>Where the fuck does it say I have to know C to program anything to do
with
>image processing, genius? Who says I have to be an expert at
anything to make
>noise about Delphi not having an unsigned 32 bit integer? Who the
fuck made
>you the complaint department?
>
>> What language DO you use for your image processing work? And
what's
>>an EXAMPLE of some image-processing task that you want to do that's
made
>>impossible or even more difficult by the fact that there's no
unsigned
>>longint in Delphi? (Do you have any clue whatever?)
>
>Prior to Delphi it was in 68K assembly, which handily happens to have
no
>restriction on 32 bit integers. I don't have a handy example for you.
Does
>that automagically negate my need down the road for an unsigned 32
bit
>integer?
So, please tell all of us, what exactly can't you do with a SIGNED
integer, you could do with an UNSIGNED integer. Just the simple
arithmetic or logical operations, not your entire image processing
code.
Signed or unsigned is just a matter of interpretation. The storage is
*excatly* the same. So if it comes to logical operations like or, and,
xor or combinations of these, there's absolutely no difference
whatsoever.
If it comes to subtraction or addition, there's also no difference.
The results just wrap around. If it comes to multiplication or
division, there *is* a difference. If it comes to comparison, there's
also a difference.
So please inform us (in a polite way please), which instructions are
keeping you from reaching your result.
BTW. You told you used 68k assembly before. Why don't you try to use
Intel assembly for the critical routines instead?
Why did you use assembly before? Weren't there any languages on the
Amiga, that provided UNSIGNED integers? Or is it because they were too
slow? And why are you criticizing Delphi then?
>Fuck off. If you don't care to see the language improved, fine. I
don't happen
>to take the sheep attitude you have and accept blindly what's been
given out
>with Delphi. Maybe I want it to have some things it should have
fucking had
>from the beginning. I just love this attitude that if it wasn't in
there then
>it shouldn't ever be in there. Maybe you're secretly M$ shills.
I suppose you mean most of us. I've seen a lot of very sensible and
informative comments and articles from most of the people (e.g.
Harvey, Lee, Sundial, Ullrich, Collins, LLoyd), who answered to your
questions. They're all not sheep or morons and certainly no M$ shills.
And keep your language a bit down. I suppose we would all like to see
the language improved. It *is* improved most of the time (at least
from the days of TP3 on - 1984? - , there were improvements on every
version change). I'm afraid you should first learn a bit more about
Delphi and then complain about it. Of course, every language has it's
shortcomings, but that's no reason to throw it away entirely. It's no
reason to "shout" at people who try to explain to you either.
Rudy Velthuis
David Ullrich
darksoft wrote:
> [...]
> > Lemme get this straight. You're an expert on image processing but you
> >don't know any C. You're a big enough expert on image processing to make
> >all this, um, fucking noise about how awful Delphi is because there's
> >no DWORDS so you can't do image processing. But you don't know any C.
>
> Where the fuck does it say I have to know C to program anything to do with
> image processing, genius? Who says I have to be an expert at anything to make
> noise about Delphi not having an unsigned 32 bit integer? Who the fuck made
> you the complaint department?
Um, if you look closely you'll find I'm not the only one disagreing
with your complaints. No, you don't have to be an expert at anything to
make noise about Delphi's lack of unsigned 32-bit integers. But you _do_
have to have some idea what you're talking about or people will just laugh.
For example:
> > What language DO you use for your image processing work? And what's
> >an EXAMPLE of some image-processing task that you want to do that's made
> >impossible or even more difficult by the fact that there's no unsigned
> >longint in Delphi? (Do you have any clue whatever?)
>
> Prior to Delphi it was in 68K assembly, which handily happens to have no
> restriction on 32 bit integers. I don't have a handy example for you. Does
> that automagically negate my need down the road for an unsigned 32 bit
> integer?
See, this is very very funny. Because if you're programming in
assembly yes that does negate the need for 32-bit unsigned integers.
You take your data, you stuff it into those signed longints, and you
pass that to the asm. Do you _really_ think that the asm is gonna
look at those bytes and know by telepathy that Delphi thinks the
high byte is a sign byte? Tee-hee, good one.
If you have an example where an unsigned 32-bit integer is
needed let us know what it is. If you don't have an example
"handy" then what are you making all the fuss about? Delphi's
BAD because it doesn't include this feature that you don't need.
Doesn't it make more sense for them to worry about things that
you _do_ need?
> Fuck off. If you don't care to see the language improved, fine. I don't happen
> to take the sheep attitude you have and accept blindly what's been given out
> with Delphi. Maybe I want it to have some things it should have fucking had
> from the beginning. I just love this attitude that if it wasn't in there then
> it shouldn't ever be in there.
Actually nobody's said that if it wasn't there in the beginning it
shouldn't ever be there. There are improvements and additions made to
Delphi all the time - we're all for it.
People have explained at great length why simply adding 32-bit
unsigned integers would not be that easy; why it would require that
a lot of stuff be changed. And people have explained at great length
why there's really no reason to worry about it. It happens very often
that people complain about no DWORDS - it happens much less often that
the complaint makes any sense. Almost always whatever the complainer
wants to do can be done with signed longints (and almost always it's
also no trouble, you just do it, don't worry about the fact that
the longint is really signed, and there's no problem.)
People have suggested "solutions" that _would_ allow unsigned
longs. Like not allowing unsigned and signed integers in the same
expression. These people haven't considered the amount of trouble
_that_ would lead to (compared to the essentially non-existent
amount of trouble caused by the lack of DWORDs. (Um, yes it causes
a lot of trouble in newsgroups - where it doesn't cause trouble
is in writing programs.))
And you haven't yet given an example of why it matters
in image processing. We have R,G,B and an alpha channel, great.
Now _exactly_ _what_ do you want to do with that longint that
you could do if it were unsigned but cant do because it's signed?
I've tried and I can't think of an example. According to you
this proves I know nothing. That may be so. So teach me something -
exactly what image-processing operation would be eaiser if Delphi
included DWORDS?
See, I must be a total idiot, because I can't think of a
graphics operation I'd want to perform that satisfies _both_ of
these criteria:
(i) the alphs channel is supposed to be treated the same as
RGB channels
(ii) the numeric value is important.
If you're making a literal copy of something that might
satisfy (i), but it doesn't satisfy (ii), so there's no problem
with longints. Otoh if you're using the alpha channel as an
alpha channel then it has a very different status in the algorithm
than the RGB channels do anyway - whether it's a DWORD or a
longint you're going to want to look at the high byte separately
and combine it with the other channels somehow, and now I don't
see why it matters whether it's a DWORD or a longint.
Tell us _why_ you need these DWORDs. Or tell us we're
total idiots because we can't read your mind.
> Maybe you're secretly M$ shills.
Probly that's it.
David Ullrich
Robert Lee wrote:
>
> Your comparison case is just the same. if mixed types are presented the cardinal
> must be typecast to longint. If its value is greater than 2 gig then you get a
> range error. If not, everything's kosher.
Consider the extremely small number of _actual_ problems caused by
the lack of unsigned integers and thewide availability of fixes for them.
Don't you think that adding rules about what kinds of integers may be
used in the same expression will cause a lot more much more serious
problems?
> We're just going round and round. It boils down to form over function.
I agree with that, but I would put the shoe on the other foot.
Seems to me that we don't really need DWORDs, we just want them because
they'd look nice. Things _function_ just fine at present.
I missed the beginning of this. Is there an actual _reason_ you
want these DWORDs, and if yes is it a problem where nobody's offered a
simple fix? Unless you have an actual problem with no simple fix then
you're the side saying that form is more important than function.
> The
> current situation makes for a nice diagram of ordinal types at the expense of true
> 32 bit unsigned values. This could be readily fixed but the view of ordinals would
> be a bit less elegant.
It's not the _view_ that would be less elegant, it's _using_ them
that would be less elegant. Or so it seems to me. The reasons people have
given for things being the way the are have nothing to do with nice
diagrams in books - the explanations why things are as they are have been
in terms of what bits go where in memory (in particular with how to deal
with 33 bits of information on a 32-bit OS).
David Ullrich
Ray Lischner wrote:
> [...]
> Using LongInt is usually adequate. For comparison and division, you
> need extra help. Download the Unsigned unit from
> http://www.tempest-sw.com/freeware/
Now, that's what I thought. But I'm just a hobbyist -
I've been informed that this doesn't cut it:
[me]
>> There's also various free unsigned-longint assembler packages
>>around, for example check Lischner's web page.
[darksoft]
>That's just a ULONG assign to a signed 32 bit integer, not the real deal. Why
>wait until half way thru a project to find out that it won't work?
I'm a total idiot, you can tell that Mr. darksoft knows what
he's talking about. When do you conjecture that Piotr will discover
it don't work - halfway through the project, earlier, later?
Not ever having done any asm I didn't realize that there was actually
a differnce between a signed byte and an unsigned byte in memory - I
thought they were the same thing, just interpreted differently by
an application. But darksoft's background is in asm; I'd like to
thank him for setting me straight on this.
(Um, sorry<ggg>.)
Robert Lee
Duncan Murdoch wrote:
Hey! what's the deal? You can't agree with his statement. He's saying
the same thing I have been. Which side of this argument are you on
anyway?
Bob Lee
Robert Lee
Duncan Murdoch wrote:
> The real point is that for the purposes of bit twiddling, it makes no
> difference whatsoever whether you use a signed or unsigned type. By
> convention, C programmers normally use an unsigned type for this, but
> you don't have to follow their conventions.
>
Can you work around this entire problem? YES. Is it going to be ugly code with
lots of typecasts? YES. A 31bit anything is inelegant. Why is it so abhorrent
to what a small modification so that a nice clean 32bit unsigned can be handled?
> BTW, I still don't know what you meant when you brought up PChar.
> Could you expand on that?
IN THE BEGINNING THERE WERE POINTERS, and it was good. They were held constant
and any modification was forbidden. Then the great unwashed asked for the
functionality of a C type char pointer, but this violated the rules of
pointers. Thus, the great unwashed were forced to typecast char pointers to
longint to modify them, but it was ugly. Finally, the great Borland showed
mercy on them and made a new type of pointer, PChar, that broke the pointer
rules but was useful. And the great unwashed were pleased.
That's all I'm asking, let Cardinal live just outside the bounds of longint,
just like PChar lives just outside the bounds of pointer.
Bob Lee
Robert Lee
Stefan Hoffmeister wrote:
> :The only beware I remember was that the pointer be in the same
> segment. This is an architectural restriction (Intel), not a compiler
> issue (Borland).
>
> Now that we have finally gotten rid of segments we can add/subtract
> pointers without caveat.
> --
Correct, but as a user you were exposed to the potential of making invalid
pointers if you weren't cautious. Borland didn't need to do that. They could
have kept PChar unmodifiable, but the risks were outweighted by the benefits. I
believe that the same is true here. The overflow risks associated with mixing
longint and a 32bit unsigned type are minimal. While the gain, less typecasting
and other fooling around, is substantial to those who would use such a type.
Bob Lee
Robert Lee
David Ullrich wrote:
> --
> David Ullrich
>
> sig.txt not found
Actually, I'm debating this this on philosophical grounds. I personally have little need
for a 32 bit unsigned. My point, which apparently I'm not making sufficiently clear, is
that you could split the signed and unsigned ordinals into two types, without breaking
any code, or requiring 33+ bits to do any calcs. The only thing that has to be added is
a range error if a 32 bit unsigned is converted to signed and the value is greater than
2^31-1.
Bob Lee
Robert Lee
Duncan Murdoch wrote:
> Under your proposal (as I understand it!) I would have to rewrite this
> as
>
> function NewCount(Count:Cardinal;Delta:integer):Cardinal;
> begin
> result := Integer(Count)+Delta;
> end;
>
Whoa! I don't want all those typecasts! Way back there, about 50 thousand messages
ago, I said something to the effect that I would NOT require all the typecasts.
Perhaps I should have mentioned it again.
You don't need any typecasts. The compiler knows whos who, and it already knows the
rules of engagement. The only thing that it doesn't know is that cardinals can be
greater than longints and so a range check (if range checking is enabled) needs to be
performed in some circumstances. This sort of range checking is no different than
that done when trying to stick a longint into a shortint. Additionally, all the
display routines need to be able to display large values properly (i.e. not typecast
them into longints as they do now).
Bob Lee
Robert Lee
I regret to inform you of the demise of my own proposal. I looked at how range checking
works and it only check upon assignment. That is intermediate values and comparisions
are never checked. My proposal would require comparisons to be checked, and so has the
potential to break old code. This is a major problem.
However, I'm pleased to report that Cardinal is really 32 bits long even in comparisons
as long as both sides are both unsigned. That is, an unsigned conditional jump is
generated. So Delphi does have a 32bit unsigned, as long as you're careful about mixing
it with signed types. The only other thing missing are StrToCardinal and CardinalToStr.
Bob Lee
Duncan Murdoch
On Sat, 31 Jan 1998 14:52:39 -0600, Robert Lee <rh...@nwu.edu> wrote:
>Duncan Murdoch wrote:
>
>> The real point is that for the purposes of bit twiddling, it makes no
>> difference whatsoever whether you use a signed or unsigned type. By
>> convention, C programmers normally use an unsigned type for this, but
>> you don't have to follow their conventions.
>Can you work around this entire problem? YES. Is it going to be ugly code with
>lots of typecasts? YES. A 31bit anything is inelegant. Why is it so abhorrent
>to what a small modification so that a nice clean 32bit unsigned can be handled?
I'm sorry, but I don't know what you're thinking of here. Could you
give an example of an expression that now needs to be full of
typecasts that would be cleaned up under your proposal? I can
certainly give one that would be messed up under it, assuming you're
talking about the proposal that would force the programmer to use
typecasts in mixed signed/unsigned expressions.
For example:
Suppose Count measures the number of items in a collection. Since
counts are always non-negative, I might decide to make Count a
Cardinal. But then I might write a function NewCount, which takes
Count and Delta and returns Count+Delta. However, Delta is just as
likely to be negative as positive, so I'd like it to be signed.
In the current language, this is perfectly reasonable code:
function NewCount(Count:Cardinal;Delta:Integer):Cardinal;
begin
result := Count+Delta
end;
Under your proposal (as I understand it!) I would have to rewrite this
as
function NewCount(Count:Cardinal;Delta:integer):Cardinal;
begin
result := Integer(Count)+Delta;
end;
or perhaps
function NewCount(Count:Cardinal;Delta:integer):Cardinal;
begin
result := Cardinal(Integer(Count)+Delta);
end;
Your turn: show me what a "nice clean 32 bit unsigned" can do.
Duncan Murdoch
Luke Webber
>>For that matter, why not disallow mixed signed/unsigned operations
>>entirely without a cast? It's really just a matter of making the
>>programmer make up his/her mind about what type of result they want if
>>their intention is unclear.
>That was done in Modula-2. I found it a massive pain in the backside
>on some occasions... you ended up with big arithmetic expressions with
>loads of casts in the middle... made it really hard to read.
Was that due to mixtures of signed/unsigned terms or did they actually
make you case int/longint terms? I don't really think you'd see a lot of
programmers using unsigned vbls unless they were dealing with things like
Winblows/Unix "sets" (ie flag boxes) or the occasional thing like the
colour values under discussion.
In any case, if they did, this type of compiler behaviour would soon cure
them of it. <g>
--
Luke Webber
* Note: The opinions expressed by Luke Webber are in no way supported *
* by his employers, Luke Webber Consulting Services *
Luke Webber
Robert Lee <rh...@nwu.edu> writes:
>David Ullrich wrote:
>Actually, I'm debating this this on philosophical grounds. I personally have little need
>for a 32 bit unsigned. My point, which apparently I'm not making sufficiently clear, is
>that you could split the signed and unsigned ordinals into two types, without breaking
>any code, or requiring 33+ bits to do any calcs. The only thing that has to be added is
>a range error if a 32 bit unsigned is converted to signed and the value is greater than
>2^31-1.
Well Bob, I was with you right up to this point, but here we part ways.
Don't make me or any other programmer have to deal with any more potential
code explosions when our programs are run in production when they worked
just fine in testing, OK?
The last thing I need is for another cause of overflow errors or GPFs or
any other damned error that isn't flaged by the compiler. That's a support
nightmare. Other than that, we're on the same side.
For me the rule should be that a compiler *warning* (not error,maybe a
hint) should be generated if I mix signed and unsigned. If I choose to
ignore that, it means I'm treating all the terms in my expression as
unsigned. That has to be the most elegant solution.
As you've already stated, the Cardinal is "inelegant". I'd go further and
say that there it is totally useless and nothing more than a distraction.
Luke Webber
Romours of the dealth of your proposal are greatly exaggerated. I think I
might still keep it alive for a while, if you don't mind.
Cardinal is not a 32-bit value because there is no way I can set the top
bit. Cardinal is therefore a red herring and a piece of clutter in an
otherwise clean and beautiful language.
If a programmer chooses to compare unsigned longints to signed longints,
and he/she knows the rules, why shouldn't he/she? The bland assumption
that we don't need that capability is one of the things that gets on my
nerves.
Suppose I'm dealing with a database which expresses its time/dates in
terms of an unsigned long offset from a given date, just like DOS and
Unix? Suppose that base date is sufficiently far in the past to mean that
tomorrow is going to give me a negative value? All the computer science
and mathematical arguments in the world aren't going to save my company
from a lawsuit if my client(s) lose millions based on an error in my code
predicated on a failure of my chosen tool to deal with the real world.
Really, I think this is one of the few places where Borland have held
Pascal back in the restrictive Jensen and Wirth mould. I'd like to see it
sorted out.
Robert Lee <rh...@nwu.edu> writes:
>Bob Lee
--
Duncan Murdoch
On 2 Feb 1998 00:05:06 +1100, lu...@oberon.sub.net.au (Luke Webber)
wrote:
>This might be a valid argument, if there was any real reason for using a
>Cardinal in this place. In fact, since Cardinal can't express any value
>higher than a longint, it's really more of an argument against ever having
>a Cardinal in the first instance.
I'll quote from the email I just wrote to you privately, to answer
this question in public:
The Cardinal is a contract: it says you've got a value which you
guarantee will never be negative, and never larger than the upper
limit. It's like any other subrange type. It makes programming
simpler, because code that deals with it can rely on the contract.
I think the problem is that C doesn't make it so easy to make these
contracts, so you're used to programming without them. Yes, you can
program that way and the machine code for your program will run just
as well, but making them helps you to write programs that don't have
errors in them.
Duncan Murdoch
Luke Webber
This might be a valid argument, if there was any real reason for using a
Cardinal in this place. In fact, since Cardinal can't express any value
higher than a longint, it's really more of an argument against ever having
a Cardinal in the first instance.
If, OTOH, there was a proper unsigned longint capable of expressing the
full range of 0 to 2^32, we could properly expect the compiler to deal
with such conditions by clearly stated rules and by emitting warnings
where considered appropriate. The kind of thing programmers deal with
every day.
Where this whole thing really falls down, though, is that it draws a
magical boundary at the 32-bit point. In physics, it's fair to set certain
limits to behaviour. The speed of light, Planck's constant, Pi. All very
useful. 32 bits is not a universal constant. It's something that will
change, and then Borland are going to have to deal with it. It would be
better if they'd dealt with it up front.
I just hope they don't create the same stupidity when the boundary is
shifted to 64 bits.
dmur...@pair.com (Duncan Murdoch) writes:
>Suppose Count measures the number of items in a collection. Since
>counts are always non-negative, I might decide to make Count a
>Cardinal. But then I might write a function NewCount, which takes
>Count and Delta and returns Count+Delta. However, Delta is just as
>likely to be negative as positive, so I'd like it to be signed.
>In the current language, this is perfectly reasonable code:
>function NewCount(Count:Cardinal;Delta:Integer):Cardinal;
>begin
> result := Count+Delta
>end;
>Under your proposal (as I understand it!) I would have to rewrite this
>as
>function NewCount(Count:Cardinal;Delta:integer):Cardinal;
>begin
> result := Integer(Count)+Delta;
>end;
>or perhaps
>function NewCount(Count:Cardinal;Delta:integer):Cardinal;
>begin
> result := Cardinal(Integer(Count)+Delta);
>end;
>Your turn: show me what a "nice clean 32 bit unsigned" can do.
>Duncan Murdoch
Martin Harvey
Verily, lu...@oberon.sub.net.au (Luke Webber) spake thus:
>mc...@cam.ac.uk (Martin Harvey) writes:
>>Verily, lu...@oberon.sub.net.au (Luke Webber) spake thus:
>>>For that matter, why not disallow mixed signed/unsigned operations
>>>entirely without a cast? It's really just a matter of making the
>>>programmer make up his/her mind about what type of result they want if
>>>their intention is unclear.
>>That was done in Modula-2. I found it a massive pain in the backside
>>on some occasions... you ended up with big arithmetic expressions with
>>loads of casts in the middle... made it really hard to read.
>Was that due to mixtures of signed/unsigned terms or did they actually
>make you case int/longint terms? I don't really think you'd see a lot of
>programmers using unsigned vbls unless they were dealing with things like
>Winblows/Unix "sets" (ie flag boxes) or the occasional thing like the
>colour values under discussion.
>In any case, if they did, this type of compiler behaviour would soon cure
>them of it. <g>
Well, It wasn't so much signed vs unsigned as length changes... ie Int
to longint etc etc ...
MH.
Kevin W. Gale
Piotr Trzcionkowski wrote in message <34f393de...@zeus.polsl.gliwice.pl>...
>
>You can use standard signed long integer. All positive numbers have
>the same contents and even operations with any positive and negative
>is correct independent from it is signed or unsigned (numbers are
>wraped). Only result you need show depends is signed or unsigned.
This is just plain wrong. For example the code similar to the following I found in
a serial comm component I grabbed off the net. (Please ignore the fact that
this is the wrong way to do serial communications under Win32)
StartTime := GetTickCount;
while True do
begin
Read from serial port
if (GetTickCount - StartTime) > 500 then
break;
end;
The subtraction and comparison are a problem. GetTickCount returns the number
of Milliseconds since the system boot. If returned as a signed number (as Delphi
does) the value rolls over after about 29 days of uptime. If the StartTime was
taken just before the rollover then the loop will not exit for another 29 days.
This is very easy to fix (and I did so). However you just cannot ignore the fact
that an API returns a DWORD if you are doing any operations on the value.
I wrote the post that started this thread. All I really wanted was an explanation
as to why Delphi has no unsigned 32 bit integer type. Duncan Murdoch answered
that question in a very nice post. Thanks again Duncan.
Kevin
Michael Caracena
Robert Lee <rh...@nwu.edu> wrote in article <34D3DF09...@nwu.edu>...
> Actually, I'm debating this this on philosophical grounds. I personally
have little need
> for a 32 bit unsigned. My point, which apparently I'm not making
sufficiently clear, is
> that you could split the signed and unsigned ordinals into two types,
without breaking
> any code, or requiring 33+ bits to do any calcs. The only thing that has
to be added is
> a range error if a 32 bit unsigned is converted to signed and the value
is greater than
> 2^31-1.
>
> Bob Lee
I have a problem:
I wish to create and access a file that is greater than 2 gigs.
Since all the file functions return long integers,
how would I get around that problem?
Borland's C++ builder has a 64 bit integer ...
why not Delphi?
Best wishes,
Michael Caracena
cara...@henge.com
Michael Caracena
Michael Caracena <cara...@henge.com> wrote in article
<01bd312c$4865e000$7797...@caracena.henge.com>...
Opps.
I meant to say a 32 unsigned integer!
( I just got done responding to a post about
running Delphi on a 64 bit DEC Alpha.)
Stefan Hoffmeister
: "Michael Caracena" <cara...@henge.com> wrote:
>Robert Lee <rh...@nwu.edu> wrote in article <34D3DF09...@nwu.edu>...
>> Actually, I'm debating this this on philosophical grounds. I personally
>have little need
>> for a 32 bit unsigned. My point, which apparently I'm not making
>sufficiently clear, is
>> that you could split the signed and unsigned ordinals into two types,
>without breaking
>> any code, or requiring 33+ bits to do any calcs. The only thing that has
>to be added is
>> a range error if a 32 bit unsigned is converted to signed and the value
>is greater than
>> 2^31-1.
>I have a problem:
>
>I wish to create and access a file that is greater than 2 gigs.
>Since all the file functions return long integers,
They return DWORD - which is NOT a long integer (and that's the whole
point of this thread).
>how would I get around that problem?
*IF* the Win32 API accepts parameters larger than 2 GB in the
"standard" API then simply pass in an integer after having turned off
range and overflow checks.
RETURNED values can be split up - just test the highest bit and you
have a "true" cardinal, with the highest bit not set, you can safely
use a longint.
See Ray Lischner's UINT unit (http://www.tempest-sw.com/) for
"unsigned long integer" comparison, output etc..
As has been said many times before in this thread:
All you need is to get 32 bit into that function and 32 bit back. It
does not matter a bit WHAT EXACTLY you squeeze in - in only should be
32 bits large.
If you like some thrill, why not get the return result into a packed
record of 4 Chars? Or an "array[0..1] of word"? [Just to make a
point.]
Admittedly this does not LOOK nice, but it WORKS as good as for signed
longints.
>Borland's C++ builder has a 32 bit integer ...
>why not Delphi?
Does C++ Builder have as extensive runtime checking as Delphi, in
particular on that 32bit UNSIGNED integer (aka DWORD)?
Duncan Murdoch
On 3 Feb 1998 17:26:04 GMT, "Michael Caracena" <cara...@henge.com>
wrote:
>Borland's C++ builder has a [32 unsigned integer]
...
>why not Delphi?
Your headers showed these references:
References: <EnGBp...@world.std.com> <34CF42F4...@nwu.edu>
<EnI3o...@world.std.com> <34d075a...@news.ccs.queensu.ca>
<34D0C90D...@nwu.edu> <34d1f438...@news.ccs.queensu.ca>
<luke.886118852@oberon> <34D13D89...@nwu.edu>
<34d8cd9b...@news.ccs.queensu.ca> <34D20541...@nwu.edu>
<34D37D...@math.okstate.edu> <34D3DF09...@nwu.edu>
The ones from news.ccs.queensu.ca are from me; I think I spent the
whole time answering "why not Delphi?"! Rather than have me do it all
again, why don't you read some of those, and if there's anything that
hasn't been brought up, ask that instead?
Duncan Murdoch
Michael Caracena
Duncan Murdoch <dmur...@pair.com> wrote in article
<34dbc31d...@news.ccs.queensu.ca>...
> On 3 Feb 1998 17:26:04 GMT, "Michael Caracena" <cara...@henge.com>
> wrote:
> >Borland's C++ builder has a [32 unsigned integer]
> ...
> >why not Delphi?
>
> Your headers showed these references:
>
> References: (surpressed)
>
> The ones from news.ccs.queensu.ca are from me; I think I spent the
> whole time answering "why not Delphi?"! Rather than have me do it all
> again, why don't you read some of those, and if there's anything that
> hasn't been brought up, ask that instead?
>
> Duncan Murdoch
Duncan,
if you wish to say "Shut Up"
why not just say it? ;-)
But, perhaps you are right,
accessing a file that is over
2 gigs doesn't belong in this thread anyway.
Perhaps, the point I should have made was
that Borland should improve there file access routines to support HUGE
FILES.
(Which should have not been in this thread.)
I apologize for the intrusion.
But, If you are tying to make the point ( in your previous posts)
that Delphi doesn't really need an unsigned 32 bit integer,
I would say that that is sort of like saying we don't need a
Word 0..65535 Unsigned 16-bit
if there is a
Smallint -32768..32767 Signed 16-bit
But you do use words, don't you?
And what about a ^Word?
Best regards,
Michael Caracena
cara...@henge.com
Duncan Murdoch
On 4 Feb 1998 23:32:19 GMT, "Michael Caracena" <cara...@henge.com>
wrote:
>if you wish to say "Shut Up"
>why not just say it? ;-)
I didn't want to say that, I just didn't want to repeat myself.
>But, If you are tying to make the point ( in your previous posts)
>that Delphi doesn't really need an unsigned 32 bit integer,
I don't think it "needs" a 32 bit unsigned, but I think adding it
would be a good idea. This was my suggestion at the end of
<34d8cd9b...@news.ccs.queensu.ca>.
Duncan Murdoch
Steve Davis
dispensing with all the crap - it appears to me that the Cardinal Type is
the same as 32 bit unsigned - _IF_ you are using D3 under Win95 or NT,
anyway.
David Ullrich
Exactly what do you do at Dell? Just curious...
Dave Shapiro
Steve Davis wrote:
>
> dispensing with all the crap - it appears to me that the Cardinal Type is
> the same as 32 bit unsigned - _IF_ you are using D3 under Win95 or NT,
> anyway.
I thought the same as well. However, do a ctrl-F7 and enter
High(Cardinal)
in the Expression box. The result? 2147483647. As Duncan Murdoch pointed
out earlier, Cardinal is a *contract* that you won't go negative, not an
architectural requirement.
Dave
Duncan Murdoch
On 5 Feb 98 19:34:34 GMT, in comp.lang.pascal.delphi.misc "Steve
Davis" <sad...@fcc.gov> wrote:
>dispensing with all the crap - it appears to me that the Cardinal Type is
>the same as 32 bit unsigned - _IF_ you are using D3 under Win95 or NT,
>anyway.
It's definitely very close. The differences are:
- range and/or overflow checking will complain if you set the high bit
(so turn off those checks)
- all constants are assumed signed, so you can't assign a value with
the high bit set unless you typecast it, e.g.
u := Cardinal($FFFFFFFF);
- the string conversion routines don't understand values with the high
bit set (so write your own)
- the logic of mixed signed & unsigned operations is Pascal logic
(i.e. convert everything to signed) not C logic (convert everything to
unsigned)
and, a last minute addition...
- high(cardinal) gives the same as high(integer), not $FFFFFFFF.
Is this a fair summary?
Duncan Murdoch
Robert Lee
Duncan Murdoch wrote:
That sums it up.
Bob Lee