On 3/22/16 9:43 AM, Michael Van Canneyt wrote:
Here we disagree. It IS buggy behavior. Delphi is not sacrosanct, it does contain bugs like any software. This is one of them.
No one here holds Delphi up on a pedestal - least of all me. My viewpoint is completely practical/funcitonal - I have to make our code base work with FPC/LCL and VCL. Given the way we use find functionality (with a mixture of naturally sorted and automatically sorted lists) it has ceased to work with both (it did previously). I want to fix that as elegantly and as effectively as possible. Making suggestions for FPC improvement is a side effect - and as we both agree TStringList.Find can use some improvement.
And I am fine disagreeing. My definition of 'bug' is again completely functional. If I knowingly stick in a naturally sorted list into Find(), the code operates as expected without error, and I get the desired result. Both user and producer operated as expected - by intention not by accident. I do not see a bug there.
If I stick in a non-sorted list (knowingly or unknowingly) then results are undefined. Is that user error or buggy code? It certainly isn't robust code and can be improved. Label it as you like I am only interested it seeing it improved.
As we have all pointed out there is some inherent issues with a function traditionally named 'find' that essentially hides input requirements (again label that as you like). Michalis has pointed out that TFSMap.Find has a similar issue.
The other weakness I see in the current traditional implementation (Delphi and FPC) is that the 'Sorted' flag is somewhat loosely coupled to the actual state of the list i.e. it can be in a sorted state and the flag does not reflect that at all. To me it seems that the flag really means 'auto sort this please'. Once it is enabled the code will sort and maintain sort. But the code is also intended to support naturally sorted lists and not induce the overhead of auto sort. In that situation the sorted property has nothing to do with the actual state of the list. IMO better designed code would account for this.
Perhaps it should have been called TStringSortedList and enforced auto sort all the way through instead of purposely handling both sorted and unsorted lists.
As to our decision to use TStringList directly. Whether we use it directly or create our own doesn't fix the code that we all agree is insufficiently robust, 'buggy', 'prone to allow bad use', or whatever label you want to use. So I find your concern touching but not applicable to the point at hand.
Furthermore TStringList has provided exactly what we needed (and we have been careful to only pass sorted - natural or automatic - to it). Why would we purposely rebuild the wheel. Libraries exist for just this.
And that's all I have to say about that (as Forrest Gump said). Thanks for the discussion.
David _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
