views:

28848

answers:

11

In most of programming languages, we preferred using a dictionary over a hashtable . What are the reasons behind it?

+36  A: 

Because Dictionary is a generic class ( Dictionary<TKey, TValue> ), so that accessing its content is type-safe (i.e. you do not need to cast from Object, as you do with a Hashtable).

Compare

var customers = new Dictionary<string, Customer>();
...
Customer customer = customers["Ali G"];

to

var customers = new Hashtable();
...
Customer customer = customers["Ali G"] as Customer;
gius
+15  A: 

In .NET, the difference between Dictionary<,> and HashTable is primarily that the former is a generic type, so you get all the benefits of generics in terms of static type checking (and reduced boxing, but this isn't as big as people tend to think in terms of performance - there is a definite memory cost to boxing, though).

Marc Gravell
+3  A: 

The Hashtable is a loosely-typed data structure, so you can add keys and values of any type to the Hashtable. The Dictionary class is a type-safe Hashtable implementation, and the keys and values are strongly types. When creating a Dictionary instance, you must specify the data types for both the key and value.

flesh
+111  A: 

FWIW, a Dictionary is a hash table.

If you meant "why do we use the Dictionary class instead of the Hashtable class?", then it's an easy answer: Dictionary is a generic type, Hashtable is not. That means you get type safety with Dictionary, because you can't insert any random object into it, and you don't have to cast the values you take out.

Michael Madsen
And also generic collections are a lot faster as there's no boxing/unboxing
Chris S
Not sure about a Hashtable with the above statement, but for ArrayList vs List<t> it's true
Chris S
Hashtable uses Object to hold things internally (Only non-generic way to do it) so it would also have to box/unbox.
Guvante
+20  A: 

FYI: In .Net Hashtable is thread safe for use by multiple reader threads and a single writing thread, while in Dictionary public static members are thread safe, but any instance members are not guaranteed to be thread safe.

We had to change all our Dictionaries back to Hashtable because of this.

Fun. The Dictionary<T> source code looks a lot cleaner and faster. It might be better to use Dictionary and implement your own synchronization. If the Dictionary reads absolutely need to be current, then you'd simply have to synchronize access to the read/write methods of the Dictionary. It would be a lot of locking, but it would be correct.
Triynko
Alternatively, if your reads don't have to be absolutely current, you could treat the dictionary as immutable. You could then grab a reference to the Dictionary and gain performance by not synchronizing reads at all (since it's immutable and inherently thread-safe). To update it, you construct a complete updated copy of the Dictionary in the background, then just swap the reference with Interlocked.CompareExchange (assuming a single writing thread; multiple writing threads would require synchronizing the updates).
Triynko
+6  A: 

People are saying that a Dictionary is the same as a hash table.

This is not necessarily true. A hash table is an implementation of a dictionary. A typical one at that, and it may be the default one in .NET, but it's not by definition the only one.

You could equally well implement a dictionary with a linked list or a search tree, it just wouldn't be as efficient (for some metric of efficient).

rix0rrr
MS docs say: _"Retrieving a value by using its key is very fast, close to O(1), because the Dictionary <(Of <(TKey, TValue >)>) class is implemented as a hash table."_ - so you should be guaranteed a hashtable when dealing with `Dictionary<K,V>`. `IDictionary<K,V>` could be anything, though :)
snemarch
+1  A: 

one more difference that i can figure out is we can not use dictionary (generics) with web services the reason is no web service standard supports genrics standard.

+1  A: 

This is not necessarily true. A hash table is an implementation of a dictionary. A typical one at that, and it may be the default one in .NET, but it's not by definition the only one.

I'm not sure that this is required by the ECMA standard, but the MSDN documentation very clearly calls it out as being implemented as a hashtable. They even provide the SortedList class for times when an alternative is more reasonable.

Promit
A: 

Notice that MSDN says: "Dictionary<(Of <(TKey, TValue>)>) class is implemented as a hash table" not "Dictionary<(Of <(TKey, TValue>)>) class is implemented as a HashTable" Dictionary is NOT implemented as a HashTable, but is implemented following the concept of a hash table. The implementation is unrelated to the HashTable class because of the use of Generics, although internally Microsoft could have used the same code and replaced the symbols of type Object with TKey and TValue. In .NET 1.0 Generics did not exist; this is where the HashTable and ArrayList originally began.

Brant
A: 

According to what I see by using reflector: [Serializable, ComVisible(true)] public abstract class DictionaryBase : IDictionary, ICollection, IEnumerable { // Fields private Hashtable hashtable;

// Methods
protected DictionaryBase();
public void Clear();

. . . } Take note of these lines // Fields private Hashtable hashtable;

so we can be sure that DictionaryBase uses a HashTable internally.

Yuriy Zaletskyy
System.Collections.Generic.Dictionary<TKey,TValue> doesn't derive from DictionaryBase.
snemarch
A: 

When you declare a variable as Dictionary(Of K, T), the new Dictionary type that is created only accepts keys of the one type and values of the other.

http://w3vb.net/vb-net-data-structures/vb-net-collections/generic-dictionary/example-dictionaryof-k-t-generic-in-vb-net