Numeric equivalent of TStringList?

[MarkMLl]

Simple question: is there such a thing, preferably allowing 64-bit keys?

MarkMLl

[dsiders]

Simple question: is there such a thing, preferably allowing 64-bit keys?

MarkMLl

These might be of interest:

https://dsiders.gitlab.io/lazdocsnext/lazutils/integerlist/index-4.html

[br4d]

Just an Idea:

how about create a new class inheriting the TStringList. Implements addAsInteger and retrieveAsInteger which simply converting the number into String and vice versa...

[Thaddy]

Tdictionary<int64,TObject> from rtl-generics or indeed similar, based on fcl: https://dsiders.gitlab.io/lazdocsnext/lazutils/integerlist/tint64list.html
I prefer the first, btw. You can also simply use TList from classes.

[MarkMLl]

how about create a new class inheriting the TStringList. Implements addAsInteger and retrieveAsInteger which simply converting the number into String and vice versa...

That had occurred to me, but the list is likely to contain from 1K to many times that number of timestamped events from a logic analyser, arriving out-of-sequence (since timing and state are dumped separately), which will need sorting before being processed sequentially.

I suppose that a way to do it would be to put the timestamp in numeric form in the object associated with each row, leaving the string portion effectively as a cached conversion.

MarkMLl

[MarkMLl]

Tdictionary<int64,TObject> from rtl-generics or indeed similar, based on fcl: https://dsiders.gitlab.io/lazdocsnext/lazutils/integerlist/tint64list.html
I prefer the first, btw. You can also simply use TList from classes.

Thanks, those look like interesting possibilities. I'd been thinking about something TList-based but for some strange reason assumed that it would, by analogy to a TStringList, sort on the pointer rather than the content.

MarkMLl

[Thaddy]

For high volumes I suggest the generics.collections version. After all, when a string representation is needed, there are always the helper functions from sysutils, like TInt64Helper.ToString, TInt64Helper.ToHexTring and family. Storing as string is too much overhead if the data is just a 64 bit value anyway. You will be able to achieve much higher speeds in collecting the data when the data is in its native format...

[jcmontherock]

You can use dynamic array:

Code: Pascal  [Select][+][-]

1. ...
2. type
3.   TIntArray = Array of Integer;
4. ...
5.  

[MarkMLl]

For high volumes I suggest the generics.collections version. After all, when a string representation is needed, there are always the helper functions from sysutils, like TInt64Helper.ToString, TInt64Helper.ToHexTring and family. Storing as string is too much overhead if the data is just a 64 bit value anyway. You will be able to achieve much higher speeds in collecting the data when the data is in its native format...

It would probably be a good excuse for me to look at generics, but I'm still a bit wary of them for anything which will eventually be put on Github etc.: while having a modern facility like that might be a good advert for FPC, insisting that the user upgrades to the latest version with no (lower-performance etc.) fallback if he's still on an older version isn't.

MarkMLl

[MarkMLl]

You can use dynamic array:

You're obviously using a somewhat relaxed interpretation of "equivalent".

MarkMLl

[PascalDragon]

For high volumes I suggest the generics.collections version. After all, when a string representation is needed, there are always the helper functions from sysutils, like TInt64Helper.ToString, TInt64Helper.ToHexTring and family. Storing as string is too much overhead if the data is just a 64 bit value anyway. You will be able to achieve much higher speeds in collecting the data when the data is in its native format...

It would probably be a good excuse for me to look at generics, but I'm still a bit wary of them for anything which will eventually be put on Github etc.: while having a modern facility like that might be a good advert for FPC, insisting that the user upgrades to the latest version with no (lower-performance etc.) fallback if he's still on an older version isn't.

Then you can alternatively use TFPGMap<> or TFPGMapObject<> from unit fgl, they are much older (2.2, 2.4 or so).

[MarkMLl]

Then you can alternatively use TFPGMap<> or TFPGMapObject<> from unit fgl, they are much older (2.2, 2.4 or so).

Thanks for that, I'll investigate.

In practice I think the absolute cutoff point is 2.2.4 since that was the point at which FPC_FULLVERSION was introduced, i.e. before that there might not even be a sensible error message telling the user what language facility is missing. I can't remember the practical result of that: it's around there that the LCL lost (maintained) GTK1 support.

Realistically 2.6.4 is also significant since that's when  case  gained the ability to handle strings, and a lot of target development and fixes went into 2.7.1... would I be safe assuming that late 2.7.1 equates to 3.0.0?

In practice I normally assume 3.2.0 because of support for CURRENTROUTINE, but try not to insist on it.

MarkMLl

[PascalDragon]

Realistically 2.6.4 is also significant since that's when  case  gained the ability to handle strings, and a lot of target development and fixes went into 2.7.1... would I be safe assuming that late 2.7.1 equates to 3.0.0?

The development versions are considered moving targets, thus yes, you can equal it to 3.0.0 (essentially the last supported 2.7.1 is the revision right before the branch )

[MarkMLl]

The development versions are considered moving targets, thus yes, you can equal it to 3.0.0 (essentially the last supported 2.7.1 is the revision right before the branch )

Thanks, I thought that was the case. I think I might in the past have referred somewhere to "late 2.7.1" as being a desirable version, but unless stuff was actually pulled out of it before release (which I don't believe to be the case) I suppose that's basically silly.

MarkMLl

[PascalDragon]

I generally wouldn't adivce to use development versions that are no longer considered to be in development. It can be a big hazzle otherwise to find out what might be wrong in case of a problem.