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). _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
