Fixed in r50217.
On 04.11.2015 02:14, Mattias Gaertner wrote:
A problem could be with such code:
>
>var
> i: SizeInt;
> j: Integer;
>begin
> k:=i+j;
>end;
>
>Because obviously on 32bit SizeInt=longint and Integer=longint, so there
>won't be a deterministic way which type wins.
Left side wins.
It can't be perfect, but it should be deterministic.
SizeInt always wins - both if it is on left side or right side because
it has a higher rank than Integer. So it is now completely deterministic.
(Under "not deterministic" I ment that "k:=i+j" and "k:=j+i" return
different types, which is the case of "left side wins".)
On 04.11.2015 05:42, Ondrej Pokorny wrote:
On 04.11.2015 02:25, Mattias Gaertner wrote:
About the table:
>We need one table for integer and one for floating-point types.
>The integer table could look like ['int64', 'sizeint', 'integer',
>'smallint'] (but with all integer types and probably a good idea to
>allow the user to modify and enhance it - e.g. a simple TStringList).
>The winner is the one closest to the left (top - smallest index).
Many libs has such types. I have not counted, but I guess the FPC
sources has hundreds of them. Probably some of them conflict each other.
So something better than a TStringList should be used.
Could you tell which one to use?
Ok, I used just a simple "array of string". It's not the fastest/best
for adding items one-by-one but there are not so many types, so who
cares... It can be easily replaced if you don't like it.
+ I may have not added all predefined types in:
function BooleanTypesOrderList: TTypeAliasOrderList;
function IntegerTypesOrderList: TTypeAliasOrderList;
function RealTypesOrderList: TTypeAliasOrderList;
function StringTypesOrderList: TTypeAliasOrderList;
you are welcome to extend them.
Ondrej
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
