[Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

Mattias Gaertner nc-gaertnma at netcologne.de
Thu Nov 5 16:02:45 CET 2015

On Wed, 4 Nov 2015 08:23:26 +0100
Ondrej Pokorny <lazarus at kluug.net> wrote:

> 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 

I meant in doubt 'Left side wins'.
For example 'somethingA+somethingB' and both types are
longint it should return somethingA.
Since codetools do not yet support operator overloading it can't
resolve correctly 'someMatrix'+'someVector'. It should
deterministically return left side, because the important type usually
is at the beginning.

> 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.

The list is seldom edited so editing does not need much speed.
Fast search is important. As long as there are only 20 types the
structure is irrelevant. But when we extend the list for all types of
the FPC packages the list gets big.

> + I may have not added all predefined types in:
> function BooleanTypesOrderList: TTypeAliasOrderList;
> function IntegerTypesOrderList: TTypeAliasOrderList;
> function RealTypesOrderList: TTypeAliasOrderList;
> function StringTypesOrderList: TTypeAliasOrderList;



More information about the Lazarus mailing list