Value Types in Hashtable are annoying (any suggestions)

  • Thread starter Thread starter Ken Durden
  • Start date Start date
K

Ken Durden

Look at this code for simply managing a count field in a hashtable.

public void Increment( EStuff e )
{
object obCurrentCount = m_hash[e];

// If its not in there yet, then add it as one and skip the
increment
if( obCurrentCount == null )
obCurrentCount = m_hash[e] = 1;
// Increment it
else
m_hash[e] = ((int) obCurrentCount) + 1;
}

Note that each access into the hashtable actually involves two
hashtable lookups. I've actually considered creating my own class-type
with reference semantics to wrap around the 'int' type (like Java's
Integer) class.

Anyone know of an existing implementation of a reference-based Integer
class? I'm not particularly concerned with efficiency in this case,
but I would guess that using a reference Integer class would be more
effecient than all the excessive boxing, unboxing, and hashtable
lookups that are required in this solution.

Thanks,
-ken
 
Ken,

You still run into the same problem if it is a reference type. Just
because it is a reference type doesn't mean that it will pre-populate the
hashtable in the case that the item does not exist. You will still get a
null return value, and you will still have to add a value for that key.

In this situation, you aren't going to be able to avoid two lookups,
regardless of what you do.

Hope this helps.
 
Ken Durden said:
Look at this code for simply managing a count field in a hashtable.

public void Increment( EStuff e )
{
object obCurrentCount = m_hash[e];

// If its not in there yet, then add it as one and skip the
increment
if( obCurrentCount == null )
obCurrentCount = m_hash[e] = 1;
// Increment it
else
m_hash[e] = ((int) obCurrentCount) + 1;
}

Note that each access into the hashtable actually involves two
hashtable lookups. I've actually considered creating my own class-type
with reference semantics to wrap around the 'int' type (like Java's
Integer) class.

Anyone know of an existing implementation of a reference-based Integer
class? I'm not particularly concerned with efficiency in this case,
but I would guess that using a reference Integer class would be more
effecient than all the excessive boxing, unboxing, and hashtable
lookups that are required in this solution.
Click to expand...

Well, I'm not aware of any particular implementations, but here's a
simple one which would probably do you...

public class MutableInteger
{
int val;

public MutableInteger
{
}

public MutableInteger (int initial)
{
val = initial;
}

public int Value
{
get { return val; }
set { val = value; }
}
}

You could override Equals, GetHashCode etc if you wish, of course...
 
Nicholas said:
Ken,

You still run into the same problem if it is a reference type. Just
because it is a reference type doesn't mean that it will pre-populate the
hashtable in the case that the item does not exist. You will still get a
null return value, and you will still have to add a value for that key.

In this situation, you aren't going to be able to avoid two lookups,
regardless of what you do.

Hope this helps.
Click to expand...

But in the case where the item is already in the hash table he can use
the reference he gets to update the object and does not need to add it
into the hashtable again (as long as the key isn't modified).
 
Back
Top