> Hi,
> Many thanks for your replies.
> On principle I expected to get the following advice. Create a simple
> class describing the mapping (both of you say this), then make a T*List*
> with all possible mappings, then make a couple of Hash functions (one Hash
> function per "sort"-type), then create some T*Hash* objects using these
> Hash functions. Somehow none of you thought about it. Why ? What's wrong
> in such approach ?
Since your IDs are just a plain numbers you can use the binary search
rather
the "hashed" search. The hash will work too but slower.
> The solution proposed by Valeri requires me to know the number of channels
> in advance (I need to set the "size" of the table, don't I),
This I did not get. What did you mean "set size" The size of the inertnal
property of
the TTable class object, that the end-user should not worry about.
> which is not
> always true (unfortunately it may happen that the number of "hardware
> electronics" channels is bigger or smaller then the number of "detector
> wires" - some "electronics" channels may be spare and/or some wires
> may be disconnected). Thus, I would prefer NOT to set any hard
> "limits" on the number of "slots".
Can you elaborate where did you see the "limits" ?
I'd like to call your attention TTableSorter class does allo you to
provide
your own "compare" method. That may involve all table columns to calculate
the table row sorted order. However from the first glance I find no need
for this
complication.
Valeri
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:50 MET