[fpc-pascal] Re: State of fcl-stl generics lib

Michael Van Canneyt michael at freepascal.org
Sun Jan 20 14:47:39 CET 2013



On Sun, 20 Jan 2013, Florian Kl=E4mpfl wrote:

> Am 20.01.2013 14:22, schrieb Michael Van Canneyt:
>>
>>
>> On Sun, 20 Jan 2013, Florian Kl=E4mpfl wrote:
>>
>>> Am 20.01.2013 11:15, schrieb Michael Van Canneyt:
>>>>
>>>>
>>>> On Sun, 20 Jan 2013, Florian Kl=E4mpfl wrote:
>>>>
>>>>> Am 20.01.2013 06:17, schrieb leledumbo:
>>>>>> No one seems to see: http://bugs.freepascal.org/view.php?id=3D23654 =
:(
>>>>>>
>>>>>
>>>>> Well, it's a new feature: just slapping another piece of code into
>>>>> fpc-stl not improving existing stuff.
>>>>
>>>> No, but adding things from time to time shows it is not dead code :-)
>>>
>>> Indeed, but the additions should follow a common goal and as far as I
>>> understood, fcl-stl shall provide opaque containers which is not the
>>> case for a tree implementation.
>>
>> ? Why not ? I see no difference with a list or collection ?
>
> A tree is something implementation specific while the fpc-stl is only
> about opaque data structures. E.g. the fpc-stl supports TSet: but the
> whole implementation is hidden. The user does not/need not to know how
> the set works internally. It could be a linked list, a tree, whatever.

For me, a tree is a data structure, just like a set, list, collection, =

queue, whatever.

Generics for me are just a way to say 'we don't know the actual data type y=
et' =

for a particular data structure, and then later create the data structure w=
ith =

a specific type.

So, in my head, it's perfectly OK to have a tree in fcl-stl.

But like I said in earlier posts: I have no affinity whatsoever with generi=
cs, =

so I'm not very well placed to make judgments.

Well, all the more reason for someone to actually take control of fcl-stl :=
-)

Michael.


More information about the fpc-pascal mailing list