Prev: Help Break-In Mockina
Next: application domain
From: Peter Duniho on 19 May 2010 12:04
G�ran Andersson wrote:
> [...]
>> The extension method only works in a situation when you could pass the
>> object directly to the HashSet constructor, and just using the HashSet
>> constructor is simpler than the above (and results in an object that
>> continues to have the "set" semantics desired).
>
> Yes, supposing that the set is the desired result. If you just want a
> list as the result, there is no specific advantage of going the way over
> a set.

Yes, but under what scenario would the list be the desired result? It
seems contrary to the original problem requirement. In general, the
HashSet<T> will offer all the same operations that a List<T> would,
including enumeration.

I could see maybe wanting the data sorted, in which case having it in a
list would be useful. But in that case, one could easily check for
uniqueness _and_ sort at the same time using, for example,
SortedDictionary<TKey, TValue>, SortedList<TKey, TValue>, or even just
an insertion sort in a regular List<T>.

>> [...] As far as the data type being
>> smaller, I doubt there will be any difference between using "object" and
>> "byte", because the value is stored inside a managed struct with other
>> data elements, the size of which is likely aligned to at least 32-bit
>> size.
>
> The implementation seems to have changed in the latest framework... The
> keys and values used to be stored in separate arrays, which would
> definitely make the value array smaller with a smaller data type.

The 2.0 CLR has the same implementation as the current one. If there
was ever an implementation that stored the values in standalone array,
it would be the 1.1 CLR which hasn't been in common use for many years.

Pete
First  |  Prev  | 
Pages: 1 2 3
Prev: Help Break-In Mockina
Next: application domain