<div dir="ltr"><div dir="ltr">Dear all,<div>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 (<a href="http://forum.lazarus-ide.org/index.php?topic=43257.0">http://forum.lazarus-ide.org/index.php?topic=43257.0</a>).</div><div><br></div><div>Andrea</div></div></div><br><div class="gmail_quote"><div dir="ltr">Il giorno ven 30 nov 2018 alle ore 09:15 Michael Van Canneyt <<a href="mailto:michael@freepascal.org">michael@freepascal.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Thu, 29 Nov 2018, Franz Müller wrote:<br>
<br>
> Hi everybody!<br>
><br>
> Currently, the implementation of cutomsorted stringlists ist very far <br>
> from satisfactory; you have to call the sort routine again whenever a <br>
> string is added to the stringlist or an item is changed, because the <br>
> stringlist cannot keep itself automatically sorted using a custom <br>
> compare function. There is a better implemetation using the <br>
> "experimental" define FPC_TESTGENERICS, but this code has not become <br>
> "mainstream" FPC for a long time now, and I feel that the use of <br>
> generics for the implementation of stringlists will also introduce quite <br>
> some unnecessary overhead.<br>
<br>
The reason for not using the generic based version is that the generics code is slower.<br>
<br>
> I would like to propose one of two versions of improvement of the <br>
> non-FPC_TESTGENERICS TStringlist, that I would also be willing to <br>
> program and to submit a patch for it.<br>
><br>
> Variation one:<br>
><br>
> Just add a property OnSort of type TListSortCompare and always sort <br>
> using the user-provided function if the property is not nil. Automatic <br>
> sorting would only occur if sortstyle=sslauto, while the behaviour for <br>
> sortstyle=ssluser would remain as before for backward compatibility.<br>
<br>
I don't see the value of this proposal.<br>
<br>
><br>
> Variation two, more flexible:<br>
><br>
> Add a property OnSort of type TStringListSortCompare, which would allow <br>
> stringlists to be sorted not only by the value of the string, but also <br>
> by the value of the fields of the associated object. In that case it <br>
> would be necessary to add a new sortstyle sslobject, which would have to <br>
> be used when OnSort uses fields from the object for comparing, as in <br>
> this case the find method cannot use binary search for locating an item, <br>
> just like for unsorted stringlists (and the stringlist wouldn't know <br>
> otherwise that it can't use binary search).<br>
<br>
I can understand an extension where you want to be able to sort on the value<br>
of an associated object. But as you point out, the Find or IndexOf will then<br>
become useless.<br>
<br>
So the question then becomes whether you would not be better off with another <br>
class altogether if you want such customized behaviour.<br>
<br>
>From what you describe, I think you should not be using TStrings (Or TStringList) <br>
at all. TStrings is a very general-purpose class for use in a GUI, which <br>
IMHO should not be burdened with additional highly specialized mechanisms.<br>
<br>
Do not forget that TStringlist is just a possible implementation of<br>
TStrings. You are free to create your own. For example, the inifiles unit has a<br>
specialized version which is optimized for containing name=value pairs.<br>
<br>
The generic lists from generics.collections, rtl-stl or even fgl seem more suitable <br>
for what you describe.<br>
<br>
Michael._______________________________________________<br>
fpc-devel maillist  -  <a href="mailto:fpc-devel@lists.freepascal.org" target="_blank">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" rel="noreferrer" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a><br>
</blockquote></div>