HastTable/IEnumerator

  • Thread starter Thread starter Neil B
  • Start date Start date
N

Neil B

Hi folks,

I seem to have a strange issue which is probably due more to my
(incorrect) assumptions about .NET collections than anything else.

When using the HashTable.Add() method, and then subsequently getting an
IEnumerator from that HashTable, what assumptions can I make about the
order in which items will be returned when using IEnumerator.MoveNext()?

Until now I have *assumed* that MoveNext() will return me the items in
the same order as they were Add()'d. My experience just this-afternoon
seems to suggest otherwise. SortedList is a potential solution I
suppose, but at the moment my keys are not a valid basis for comparison
of my objects.

Thanks in advance for any help.

Neil B
 
Neil B said:
I seem to have a strange issue which is probably due more to my
(incorrect) assumptions about .NET collections than anything else.

When using the HashTable.Add() method, and then subsequently getting an
IEnumerator from that HashTable, what assumptions can I make about the
order in which items will be returned when using IEnumerator.MoveNext()?
Click to expand...

None whatsoever. It wouldn't be entirely unreasonable to suspect that
if you created two enumerators without in any way modifying the
hashtable in the mean time, that the order of the two enumerators would
be the same, but that's about it.
Until now I have *assumed* that MoveNext() will return me the items in
the same order as they were Add()'d. My experience just this-afternoon
seems to suggest otherwise. SortedList is a potential solution I
suppose, but at the moment my keys are not a valid basis for comparison
of my objects.
Click to expand...

I suggest you keep an ArrayList for order, and a Hashtable for mapping.
 
Neil,

The order in which items are stored in a hashtable is undefined.
Therefore, you cannot make any assumptions on the order that items will
be enumerated. This an artifact of the way hashtables work.

As you mentioned the SortedList is a potential solution, though not a
good one, for maintaining order based on the key. I really don't
understand why Microsoft decided to include it instead of a top down
red black tree which is typically much faster.

The object you use as the key must implement the IComparable interface
for the SortedList to work correctly. It really isn't difficult at
all. There's only one method to write and the implementation is
typically short and simple.

The framework does not have a built in collection that maintains
temporal ordering. That is ordering based on the sequence in time that
an item was added similar to the way the old VB collection worked.
You'll have to write your own collection for that or use one that
someone else has written.

Brian
 
Brian said:
The framework does not have a built in collection that maintains
temporal ordering. That is ordering based on the sequence in time that
an item was added similar to the way the old VB collection worked.
You'll have to write your own collection for that or use one that
someone else has written.
Click to expand...

My model is the old MFC C++ CList template, which I used quite a lot
before I bit the C#/.NET bullet.

Thanks to both of you for your replies, I guess it's clear what I have
to do next.

Neil B
 
Back
Top