[fpc-devel] Stringlist customsort

[Andrea Mauri]

Dear all,
if TStringList sort will be changed, please take into account the issue
related to randomised pivot initialisation in TStringList sort and the
consequences to Random sequence (
http://forum.lazarus-ide.org/index.php?topic=43257.0).

Andrea

Il giorno ven 30 nov 2018 alle ore 09:15 Michael Van Canneyt <
michael at freepascal.org> ha scritto:

>
>
> On Thu, 29 Nov 2018, Franz Müller wrote:
>
> > Hi everybody!
> >
> > Currently, the implementation of cutomsorted stringlists ist very far
> > from satisfactory; you have to call the sort routine again whenever a
> > string is added to the stringlist or an item is changed, because the
> > stringlist cannot keep itself automatically sorted using a custom
> > compare function. There is a better implemetation using the
> > "experimental" define FPC_TESTGENERICS, but this code has not become
> > "mainstream" FPC for a long time now, and I feel that the use of
> > generics for the implementation of stringlists will also introduce quite
> > some unnecessary overhead.
>
> The reason for not using the generic based version is that the generics
> code is slower.
>
> > I would like to propose one of two versions of improvement of the
> > non-FPC_TESTGENERICS TStringlist, that I would also be willing to
> > program and to submit a patch for it.
> >
> > Variation one:
> >
> > Just add a property OnSort of type TListSortCompare and always sort
> > using the user-provided function if the property is not nil. Automatic
> > sorting would only occur if sortstyle=sslauto, while the behaviour for
> > sortstyle=ssluser would remain as before for backward compatibility.
>
> I don't see the value of this proposal.
>
> >
> > Variation two, more flexible:
> >
> > Add a property OnSort of type TStringListSortCompare, which would allow
> > stringlists to be sorted not only by the value of the string, but also
> > by the value of the fields of the associated object. In that case it
> > would be necessary to add a new sortstyle sslobject, which would have to
> > be used when OnSort uses fields from the object for comparing, as in
> > this case the find method cannot use binary search for locating an item,
> > just like for unsorted stringlists (and the stringlist wouldn't know
> > otherwise that it can't use binary search).
>
> I can understand an extension where you want to be able to sort on the
> value
> of an associated object. But as you point out, the Find or IndexOf will
> then
> become useless.
>
> So the question then becomes whether you would not be better off with
> another
> class altogether if you want such customized behaviour.
>
> From what you describe, I think you should not be using TStrings (Or
> TStringList)
> at all. TStrings is a very general-purpose class for use in a GUI, which
> IMHO should not be burdened with additional highly specialized mechanisms.
>
> Do not forget that TStringlist is just a possible implementation of
> TStrings. You are free to create your own. For example, the inifiles unit
> has a
> specialized version which is optimized for containing name=value pairs.
>
> The generic lists from generics.collections, rtl-stl or even fgl seem more
> suitable
> for what you describe.
>
> Michael._______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20181130/708ad9e1/attachment.html>