String or Object Keys for TMap?

BlitzMax Forums/BlitzMax Programming/String or Object Keys for TMap?

Czar Flavius(Posted 2010) [#1]
TMaps can use either strings or object as keys, but which is best? So far I've been using mainly strings as it seemed simpler, but now I'm thinking that objects might be best. Strings can be of varying length, whereas I'd imagine objects are of constant size. Each newly created object would also be unique, so I wouldn't need to worry about that. At the moment I have a numeric counter which is incremented by one each time an object is made, and that number is stored as a string to give each object a unique id. Like this,
Method New()
	Global next_id:Long = 0
	id = String(next_id)
	next_id:+1
	i_am_a_map.Insert(o.id, o)
End Method


But I could also do this?

..
Field id:Object = New Object
..
Method New()
	i_am_a_map.Insert(o.id, o)
End Method


It's easy, it's a unique id, it's a constant size id... but it seems a rather hacky solution. Any ideas?


Gabriel(Posted 2010) [#2]
Sorry if I'm missing something but I'm forced to ask why you're using a TMap at all. From what you've shown, I can't think of a good reason not to be using an array.


Czar Flavius(Posted 2010) [#3]
Because objects will be created and destroyed at will, but will also needed to be accessed directly.


N(Posted 2010) [#4]
You could use something like Number Class Cluster instead of a string for the key.


Gabriel(Posted 2010) [#5]
Because objects will be created and destroyed at will, but will also needed to be accessed directly.

The key word in that sentence is "directly". You're using an associative container, so the objects are not being accessed directly, they're being accessed via tree traversal, based on a key that you don't seem to need or use. I don't doubt that moving from strings to objects will mitigate the performance cost, I'm just not clear on why you want a performance cost in the first place.


Dreamora(Posted 2010) [#6]
strings are objects so there is no overhead or anything.
strings just might take a slight higher time to insert and be found due to the fact that string compare does a byte per byte compare to find the "larger / smaller" one for these operations.

should you only need a restricted compare depth because you know that only the first 3 are imported or something, an own comparision function would be an idea.

though I'm beeing forced to agree with Gabriel: You have an int id, so what is preventing you from using a structure thats better suited for this usage?
As you need to generate unique ids anyway in that case, a straight array would be the natural solution as you will need it to hold the "used ids" anyway, so you could just as well store objects instead of booleans in the array


Czar Flavius(Posted 2010) [#7]
But if I use a straight array, when objects are deleted won't that leave big holes in the array?

I need to access objects directly by their id as it's a network game, so update packets will concern a particular object which they denote with an id (and something to change about it). For that reason I've realised using objects won't be useful for keys, as their memory addresses will be different on each computer.


Arowx(Posted 2010) [#8]
Yes but you could have a list to store empty id's and use that to select the next new ID, this would help prevent you needing to resize the array.


Czar Flavius(Posted 2010) [#9]
That's a good idea.