On Sat, 3 Feb 2007, Marco van de Voort wrote:
> > Yes it will, because the reallocations don't happen as often. > > The sorting introduces an overhead anyway, whether you set capacity or not. > > Yes, but I was talking about slowness in general, not just from the heap. > > And TStringList with those huge internal list has to move on avg half of the > array. If TStringList had an extra indirection (array of ptr to blk of ptrs) > it would be less so. Eh ? What happens if you do a Insert(0,'SomeString') ? Don't you need to move across all blocks ? Or will you just grow the first block ? Anyway, it could be a nice idea to implement as TLargeStringList. > > > The correct procedure IMHO is > > - Set capacity > > - Load > > - Sort > > > I tested such things with an N^3 algorithm for my daytime job, and the > > difference is very noticeable. > > With a single array or a multilevel one? Multilevel. > > > All this doesn't exclude that a specialized class may be more suitable for > > the job. > > To be honest, the only good point of TStringList seems to be that it is > default available on all Object Pascal. The specialised stuff (splitting > strings) is also plagued with oddities. (most notably the fact that > characters under space are always used as separator) Why do you call this oddities ? For GUI programming (and that's what it was implemented for) it makes perfect sense. > > > I just want to illustrate that, if programmed correctly, TList, > > TStringList and friends can still get you a long way... > > I think that the lengths to which people will go to stick to them paints > what is needed to make a serious effort to make them legacy. I fail to see why, but no doubt you have your reasons. I'd like to see a complete list of 'issues' with TStrings (not TStringList, that's just a specific implementation). Maybe we can then create a TFPStrings which would be interface compatible, (in the sense that it can replace TStrings without source changes. It can have internal differences, like the space handling) but with a more sensible behaviour ? I mean, I know since some time you don't particularly like tstrings and tlist and whatnot (although I don't fully know why), but, by all means: let's then do an effort and design something better. Starting with a list of issues seems like a good beginning. > > There should be a set of container classes in a separate unit (a unit not > existing in Delphi most notably) that is Open Source and works on Delphi > too. Like Decal was set up to be ? I'm all for starting such a thing. I would be the first one to use such a beast if it was better. It was the prime reason for implementing TFPlist. Michael. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
