Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2006-05

sort procedure of T(FP)List

5 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marc Santhoff

Hi,

i wonder why the declaration of the comparing function of list objects is the way it is:

TListSortCompare = function (Item1, Item2: Pointer): Integer;

Since I am writing a class that sorts a list it owns depending on another property naming the property of the list items for sorting, I would like to have it made a "procedure of object":

TListSortCompare = function (Item1, Item2: Pointer): Integer of object;

I'm dealing with lists of files and directories that should get sorted by name, date, ...
If the comparing function is a plain non object function I have to make some sort of unit global variable or the like for telling it, what property is the sort criteria. I don't like this design, although in this case there is only one soritng process at a time.

Is this a concession imposed by Delphi compatibility?

(If you can suggest a better strategy for using this stuff, please do.)

TIA;
Marc
Geno Roupsky
to Marc Santhoff

2006/5/2, Marc Santhoff :

Show quoted text 22 lines
Hi, i wonder why the declaration of the comparing function of list objects is the way it is: TListSortCompare = function (Item1, Item2: Pointer): Integer; Since I am writing a class that sorts a list it owns depending on another property naming the property of the list items for sorting, I would like to have it made a "procedure of object": TListSortCompare = function (Item1, Item2: Pointer): Integer of object; I'm dealing with lists of files and directories that should get sorted by name, date, ... If the comparing function is a plain non object function I have to make some sort of unit global variable or the like for telling it, what property is the sort criteria. I don't like this design, although in this case there is only one soritng process at a time. Is this a concession imposed by Delphi compatibility?

It is in fact Delphi that did it that way

(If you can suggest a better strategy for using this stuff, please do.)

In fact you could have different function for every kind of sort and switch them on the fly when the properties determining the kind of sort that should be made changes. In my experience there is no much code duplication involved in this technique and you could make for example one compare function for every field, after that you make a _complex_ ones calling the simple ones.

Either way it is not very OO based approach but of course you could make a descendand class of tfplist and add you own sorting code.

Geno Roupsky
Marc Santhoff
to Geno Roupsky
Geno Roupsky wrote 6 lines
In fact you could have different function for every kind of sort and switch them on the fly when the properties determining the kind of sort that should be made changes. In my experience there is no much code duplication involved in this technique and you could make for example one compare function for every field, after that you make a _complex_ ones calling the simple ones.

The only thing I'm afraid of is stumbling into threading issues in the future (most likely when I have fogotten the details of sorting ;).

Either way it is not very OO based approach but of course you could make a descendand class of tfplist and add you own sorting code.

This is what I did.

Thanks,
Marc

Geno Roupsky
to Marc Santhoff

2006/5/6, Marc Santhoff :

Show quoted text 11 lines
Am Freitag, den 05.05.2006, 11:03 +0300 schrieb Geno Roupsky: > In fact you could have different function for every kind of sort and > switch them on the fly when the properties determining the kind of > sort that should be made changes. In my experience there is no much > code duplication involved in this technique and you could make for > example one compare function for every field, after that you make a > _complex_ ones calling the simple ones. The only thing I'm afraid of is stumbling into threading issues in the future (most likely when I have fogotten the details of sorting ;).

It is the response of the compare function not the sorting one to synchronize whatever global(outside it's scope) variables is accesses, so no matter what approach you take you still will have issues with threads.

Geno Roupsky
Marc Santhoff
to Geno Roupsky
Geno Roupsky wrote 25 lines
2006/5/6, Marc Santhoff : Am Freitag, den 05.05.2006, 11:03 +0300 schrieb Geno Roupsky: > In fact you could have different function for every kind of sort and > switch them on the fly when the properties determining the kind of > sort that should be made changes. In my experience there is no much > code duplication involved in this technique and you could make for > example one compare function for every field, after that you make a > _complex_ ones calling the simple ones. The only thing I'm afraid of is stumbling into threading issues in the future (most likely when I have fogotten the details of sorting ;). It is the response of the compare function not the sorting one to synchronize whatever global(outside it's scope) variables is accesses, so no matter what approach you take you still will have issues with threads.

Yes, and it is much easier to deal with this in objects as instances of classes than to do it on procedure level counting bytes with getmem (imo).

That's why i wanted to use a function of object (avoiding nasty globals). I've written it already ans it is very clear and compact.

Regards,
Marc