[fpc-devel] Stringlist customsort

[Tomas Hajny]

Hello all,

Please note that the original poster (in Cc: of this e-mail) is not
subscribed to the list. I don't know if he has access to the list using
some other method, or whether he just forgot to mention that he wasn't
subscribed to the list in his message, but it might be better to include
him in Cc: of messages for this topic unless he states otherwise.

Tomas
(one of FPC mailing list moderators)


---------------------------- Original Message ----------------------------
Subject: Re: [fpc-devel] Stringlist customsort
From:    "Andrea Mauri" <andrea.mauri.75 at gmail.com>
Date:    Fri, November 30, 2018 14:29
To:      "FPC developers' list" <fpc-devel at lists.freepascal.org>


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20181130/97429541/attachment.html>