[fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()
Michael Van Canneyt
michael at freepascal.org
Sat Feb 3 18:59:33 CET 2007
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?
> > 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
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
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.
More information about the fpc-pascal