[fpc-pascal] FPImage and GetDataLineStart

[Florian Klämpfl]

Am 22.04.2011 00:31, schrieb Michael Van Canneyt:
> 
> 
> On Thu, 21 Apr 2011, Sven Barth wrote:
> 
>> On 21.04.2011 21:45, Michael Van Canneyt wrote:
>>>
>>>
>>> On Thu, 21 Apr 2011, Marco van de Voort wrote:
>>>
>>>> In our previous episode, Michael Van Canneyt said:
>>>>>
>>>>> You can propose whatever you want _but_ generics.
>>>>
>>>> Motivation?
>>>
>>> Threefold:
>>> a) The compiler's handling of generics is still beta code in my opinion.
>>> As far as I know, the original problem I reported when writing the docs
>>> for them is still not solved.
>>>
>>
>> May I ask out of curiosity which problem you mean?
> 
> There were several.
> 
> The first one seems solved (see docs, section on 'A word on scope', the
> local thing), compiler now gives an error (a debatable solution IMHO,
> but better than the crash at the time.).
> 
> Second problem:
> 
> The following compiles:
> 
> uses ucomplex;
> 
> type
>   Generic TMyClass<T> = Class(TObject)
>     Function Add(A,B : T) : T;
>   end;
> 
> 
> Function TMyClass.Add(A,B : T) : T;
> 
> begin
>   Result:=A+B;
> end;
> 
> 
> Type
>   TMyIntegerClass = specialize TMyClass<Integer>;
>   TMyComplexClass = specialize TMyClass<Complex>;
> 
> end.
> 
> but the following does not:
> 
> ---------------------------------------------------------
> unit mya;
> 
> interface
> 
> type
>   Generic TMyClass<T> = Class(TObject)
>     Function Add(A,B : T) : T;
>   end;
> 
> Implementation
> 
> Function TMyClass.Add(A,B : T) : T;
> 
> begin
>   Result:=A+B;
> end;
> 
> end.
> ---------------------------------------------------------
> 
> and program :
> 
> ---------------------------------------------------------
> program myb;
> 
> uses mya, ucomplex;
> 
> Type
>   TMyIntegerClass = specialize TMyClass<Integer>;
>   TMyComplexClass = specialize TMyClass<Complex>;
> 
> end.
> ---------------------------------------------------------
> 
> Results in:
> 
> home: >fpc -S2 myb.pp
> mya.pp(16,12) Error: Operator is not overloaded: "complex" + "complex"
> myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping
> 
> Which is strange to say the least, as the per the definition/intent of
> generics, the code in mya should not know anything about the types that
> will be used when specializing. (in this case complex).
> 
> As per the intent of generics the second program above should compile
> just as well.
> 
> But then different rules will apply for operators and procedure calls:
> - procedure calls must be resolvable at define time
> - Operators must be resolvable at specialization time.
> No principal problem (we can define it so), but strange at least.
> 

It is correct that the second doesn't compile. To make the second
compile, the overloaded operators for the complex type must be defined
inside complex (which was/is? not possible).