But:
If the variable is already QWORD, no point for the warning:
Pascal languages prefer signed types to unsigned types thus such a constant is treated as Int64 instead of QWord. This is by design.
But, is this the point of such ridicilous warnings that compiler have to teach me what I want (???) , or that I tell to compiler exactly what I want?
Best read the comments of this (https://bugs.freepascal.org/view.php?id=34864) bug report which was essentially about the same topic.
If the compiler support Uint64 natively, then that is the highest integer type, not int64. Decision that that is int64 have no sense at all.
Best read the comments of this (https://bugs.freepascal.org/view.php?id=34864) bug report which was essentially about the same topic.
And this bug report was rejected?
If the compiler support Uint64 natively, then that is the highest integer type, not int64. Decision that that is int64 have no sense at all.
There will be no changes. We are here in a church . Not in a parliament!
So Wirth recogniced his mistake.
Only fpc has not recognized that.
So Wirth recogniced his mistake.
Only fpc has not recognized that.
I'm not sure I get your point on this...
But if Delphi makes something correct (seldom enough) this is not adapted:
From http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants (http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants)
Winni
Every bloody mistake and error of Delphi or Turbo Pascal must be copied.
To make it "compatible".
Again: Pascal has a preference for signed types, thus it's irrelevant that an unsigned type exists that has the same width.
Again: Pascal has a preference for signed types, thus it's irrelevant that an unsigned type exists that has the same width.
Actually, where that is wrote? Can you point relevant document?
It also stems from points such as ISO Pascal only defining a signed integer type as required type.
You better take Turbo Pascal.
Another useless ISO standard.
ISO-Pascal is from 1990. The extended version (nobody uses hat) is from 1991.The goal of the ISO standards was - and still is - to be able to write compilers on very different hardware and still maintain sourcecode compatibility.
It has no objects. It is just unusable.
But if Delphi makes something correct (seldom enough) this is not adapted:
From http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants (http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants)
All PASCAL's have this, J&W too. But there are good reasons for it (see e.g. https://stackoverflow.com/questions/12781434/why-do-delphi-and-free-pascal-usually-prefer-a-signed-integer-data-type-to-unsig/12782028#12782028 ), most notably in determining range and associated checking. Lesser languages don't have those features (and note, in C too the base type is int and not unsigned int)
The simple solution is to never use arithmetic with the largest unsigned integer and only use it for bitfields etc.
#include <iostream>
using namespace std;
int main()
{
if (0xFFFFFFFFFFFFFFFF < 0)
cout<<"0xFFFFFFFFFFFFFFFF is less than 0!" ;
else
cout<<"0xFFFFFFFFFFFFFFFF is unsigned!" ; // Always executable
return 0;
}
#include <stdio.h>
int main()
{
if (0xFFFFFFFFFFFFFFFF < 0)
printf("0xFFFFFFFFFFFFFFFF is less than 0!") ;
else
printf("0xFFFFFFFFFFFFFFFF is unsigned!") ; // Always executable
return 0;
}
This is incorrect. That value is large than the signed integer type. IOW it is a hack, and range check for the type is probably broken.
If the compiler support Uint64 natively, then that is the highest integer type, not int64. Decision that that is int64 have no sense at all.
const
HexConst = $FFFFFFFFFFFFFFFE;
begin
WriteLn (HexConst);
end.
const
HexConst = $FFFFFFFFFFFFFFFE;
var
I: int64;
Q: qword;
begin
I := HexConst;
Q := HexConst;
I := I div 2;
Q := Q div 2;
WriteLn (I);
WriteLn (Q);
end.
Let assume FPC documentation and decision where wrong,
and let focus on Delphi and Embarcadero decisions and documentations.
Or better to focus on C/C++ standards as these standards are way mature. Currently there is no larger signed type than int64, but there is unsigned int64 (unt64) which is on the top on hiearchy, thus it is clear that uint64 literals should not be implicitly converted to int64, nor int32.
Anyone here read C/C++ standards? They can be considered as "Holy Grail" and the best reference to others as they are the most mature.
For instance, in JAVA, there is no signed types by design, which is basic and an arbitrary decision of the Gosling, Sheridan, and Naughton. Among missing pointers and endless revisions, that is its main flaw in design.
But here, in Pascal (as in C/C++), we have signed and unsigned integers and we know what is hierachy order for integer types and what to do with. Or we don't? I personaly believe FPC made a mess here with this arbitrary decision.
The allways used logic is
MaxUnsingnedXX = 2 * MaxIntXX +1;
Example: 16 Bit : MaxWord = 2 * MaxSmallInt +1 : 65535 = 2 * 32767 +1
I did not talk about typecasting nd what fits in registers,
I did talk about simple multiplying with my brain! Gosh!
And do you know this:
MaxCardinal := 2 * MaxInt32 + 1 // brain, not registers
This is from N. Wirth himself. In Modula II.
Circular reasoning. It is wrong because we assume it is wrong?
Bingo, success! C has postfix designations for literals to assign them the right type. Pascal does the same by a typecast that is also allowed in e.g. constant declarations.
So there is no way to have a negative number? How odd.
And the hierarchy is clear in Pascal. The largest signed type is the top of the of all, and literals have the type, the corresponding unsigned type doesn't fit in its range so is orphaned.
And it is not. Why again? Becuse it is wrong! Similar to 16, 32 and 64-bits CPUs and 128 in the future. Except now for current 64-bits CPUs is not the case. If you follow the logic, follow it consistently, always!
Circular reasoning. It is wrong because we assume it is wrong?
You are aware of technique called "Proof by contradiction" ?
QuoteBingo, success! C has postfix designations for literals to assign them the right type. Pascal does the same by a typecast that is also allowed in e.g. constant declarations.
Look these examples I posted in C and C++ and tell me what is the difference comparing to the same code with FPC.
QuoteSo there is no way to have a negative number? How odd.
They have only signed numbers. My bad English (fixed). Anyone worked or studied JAVA know that weirdness.
QuoteAnd the hierarchy is clear in Pascal. The largest signed type is the top of the of all, and literals have the type, the corresponding unsigned type doesn't fit in its range so is orphaned.
How that can be? Signed type have 2nd complement N-1 bits mantissa (N bit, i.e. MBS is just a sign), while unsigned have N bits of mantissa?
Let take a signed and unsigned 8-bit integer. What is on top 7 or 8 bit of mantissa? Or simply, what is higher 127 or 255?
If we stick on current logic for 64-bits with 64 bit CPUs, then this should be the case in FPC for 8-bit CPUs:
Again, what is the case in Rio for the same 64-bit example code?
You are familiar with the term "gaslighting" ?
I don't know. Embarcadero is notoriously bad in publishing language rationales. But maybe they implemented a native int128 type for 64-bit only. Does it compile in 32-bit ?
I don't know. Embarcadero is notoriously bad in publishing language rationales. But maybe they implemented a native int128 type for 64-bit only. Does it compile in 32-bit ?
Exactly, you do not know, but stii claim that decision regarding this you have made is correct.
The main problem is that you are so touchy that on anything wrote here you react as a childs. Gosh!
I point here on logical bug and probably Delphi incompatibility, suggesting to test and correct.
QuoteI don't know. Embarcadero is notoriously bad in publishing language rationales. But maybe they implemented a native int128 type for 64-bit only. Does it compile in 32-bit ?
Exactly, you do not know, but stii claim that decision regarding this you have made is correct.
http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants
According to this, they didn't developed int128 type, but then again, I see no logic why constant literals are probably not automatically converted to int64, as in FPC. I just asking confirmation from someone have Rio - I do not have it.
Ironically, you don't know either (since you are seeking confirmation), but you are still certain that the decision is wrong.
Try to discuss more rational and to the point, and you get less sentiment back.