[Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX
lazarus at kluug.net
Wed Nov 4 08:23:26 CET 2015
Fixed in r50217.
On 04.11.2015 02:14, Mattias Gaertner wrote:
>> A problem could be with such code:
>> > i: SizeInt;
>> > j: Integer;
>> > k:=i+j;
>> >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.
More information about the Lazarus