[fpc-pascal] What is the portable approach?

[Marco van de Voort]

> I have data that would fit an associative array if they really
> existed in Pascal, but while the key is a string, the values are
> reals [0,1].  So, I have been using a TStringList and something like
> (from memory):
> 
> MyList.AddObjects('key1',pointer(round(value1*maxint));
 
(effectively making fixed point coded reals)

> I realized that someday I might get burned on a 64-bit machine ...
> now (using 2.0) I am reminded of this each time I compile.

No, it remains working I think. However you won't increase precision.
(effectively using 31-bit of the 64 bit pointer)
 
> So.. what's the portable method?  I could declare a real on the heap
> and store the pointer to it.  Or I could write an object to hold the
> real and instansiate a new object when I add a record?  Or I could
> store the values as text using the psuedo-associate properties of
> TStringList?

I think abusing a stringlist is bad. Moreover stringlists scale bad if
you stuff more than a 10-20k entries in them.

I have some set and map procedures, but while these are reasonably clean
at the interface level, the implementation is not even close to portable.

However they still have the allocation problem. (value pointer to record with
a real in it). 

If you know upfront how many pairs you'll get, you can allocate all
reals together (as array of reals), and store pointers that point to
the values in the array. However be careful to never setlenght or reallocate
the array, since that will fail.

This will save you the allocation performance (runtime) overhead, as well
as the 4 or 8 byte or so heapmgr overhead per allocation, though it
still costs a pointer.
 
> Is one of them the right/accepted/guru way to do it?  Or am I missing
> an alternative?  Should I be thinking of extending the TStringList

Don't. Create an own datastructure that is a true map. Tstringlist and tlist
really shouldn't be used as basetypes for datastructures since they
scale bad.