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 < mich...@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@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel >
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel