[fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[Sven Barth]

Am 27.01.2016 12:15 schrieb "Maciej Izak" <hnb.code at gmail.com>:
>
> 2016-01-27 12:07 GMT+01:00 Michael Van Canneyt <michael at freepascal.org>:
>>
>> On Wed, 27 Jan 2016, Juha Manninen wrote:
>>>
>>> Yes, that is about your Generics.Collections compatibility.
>>> I was more interested why fcl-stl is not Delphi compatible while many
>>> other libraries provided by FPC project are.
>>
>>
>> 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
>> C# or Delphi functionality (hence the name stl: Standard Template
Library).
>
>
> Delphi Generics.Collections exist since Delphi 2009. fpc-stl was
introduced around 2012
>
> 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  :
>
>
http://stackoverflow.com/questions/17951412/what-does-the-default-tarray-sort-comparator-actually-do-and-when-would-you-use

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 pinpoint.it? ;) ). 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).
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...

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.

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.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20160127/0e844f3f/attachment.html>