<p>Am 27.01.2016 12:15 schrieb "Maciej Izak" <<a href="mailto:hnb.code@gmail.com">hnb.code@gmail.com</a>>:<br>
><br>
> 2016-01-27 12:07 GMT+01:00 Michael Van Canneyt <<a href="mailto:michael@freepascal.org">michael@freepascal.org</a>>:<br>
>><br>
>> On Wed, 27 Jan 2016, Juha Manninen wrote:<br>
>>><br>
>>> Yes, that is about your Generics.Collections compatibility.<br>
>>> I was more interested why fcl-stl is not Delphi compatible while many<br>
>>> other libraries provided by FPC project are.<br>
>><br>
>><br>
>> It was donated by someone early on during the implementation of generics. I don't think the comparable Delphi units existed at the time. I think the implementation was more based on C++ templates/generics than on comparable<br>
>> C# or Delphi functionality (hence the name stl: Standard Template Library).<br>
><br>
><br>
> Delphi Generics.Collections exist since Delphi 2009. fpc-stl was introduced around 2012<br>
><br>
> FPC generics implementation was very buggy, was almost impossible to implement compatible version, and there was lack of Generics.Defaults comparable functionality (which is base for any collection - especially _LookupVtableInfo function). More info about _LookupVtableInfo  :<br>
><br>
> <a href="http://stackoverflow.com/questions/17951412/what-does-the-default-tarray-sort-comparator-actually-do-and-when-would-you-use">http://stackoverflow.com/questions/17951412/what-does-the-default-tarray-sort-comparator-actually-do-and-when-would-you-use</a></p>
<p>Thank you for the link, because now I know what was *really* bugging me about the code all the time (you know that feeling that you instinctively know that something is wrong, but you can't really <a href="http://pinpoint.it">pinpoint.it</a>? ;) ). The point is that it is not necessarily guaranteed on each and every platform that the parameter passing of a (interface) method is the same as for a global function with an additional instance parameter. This *might* be true for those platforms on which Windows runs and thus we need to correctly support COM interfaces, but on other platforms this *could* be completely different (e.g. a platform could pass the instance in a register instead of the stack while normal functions get all their parameters from the stack; this would totally mess up the parameters that the functions expects). <br>
And *this* is something I don't want to deal with as this could potentially break every time we improve or fix something in the parameter passing code and then only for specific platforms...</p>
<p>So if you would instead change the code to use real class instances that implement the interfaces (they can be lazily allocated singletons or so) then I'd definitely be inclined to include the code in trunk.</p>
<p>And before you say that Delphi does it differently: the Delphi developers only have to maintain the code for 3 platforms (i386, x86_64 and ARM), we however have more to maintain and thus the chances for breakage are higher.</p>
<p>Regards,<br>
Sven</p>