[fpc-pascal] Question on how to avoid memory trouble using FindFirst(), FindNext() and FindClose()

[Michael Van Canneyt]

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.