Generic Dictionary For Keys Only?

[Phil Sandler]

All,

I have a situation where I need a List<stringthat performs like a
generic dictionary (Dictionary<string, string>). Essentially, I just
need the key, not the value, so I want to use as little memory as
possible. Currently I am setting all the values of the dictionary to
null.

The List<stringdoesn't work because I am doing a lot of .Contains()
or .ContainsKey(), and lookup speed is pretty critical.

So, does such a thing exist? A dictionary that only uses a key, with
no value? Or does making the value null eliminate any memory overhead
anyway?
Thanks for any insight.

Phil

[Jon Skeet [C# MVP]]

On May 27, 3:17 pm, Phil Sandler <[e-mail]:

<snip>

So, does such a thing exist? A dictionary that only uses a key, with
no value? Or does making the value null eliminate any memory overhead
anyway?

What you're after is a set, basically. There *is* one in .NET 3.5:
System.Collections.Generic.HashSet. If you're not using .NET 3.5, I
don't believe there's one available in the framework - it's easy to
build the right interface using Dictionary, although that won't get
you any efficiency improvements.

How many elements are you likely to have in here? In many cases any
resource usage improvement will be negligible.

Jon

[Phil Sandler]

[...]

On May 27, 11:44 am, "Jon Skeet [C# MVP]" <[e-mail]:

What you're after is a set, basically. There *is* one in .NET 3.5:
System.Collections.Generic.HashSet. If you're not using .NET 3.5, I
don't believe there's one available in the framework - it's easy to
build the right interface using Dictionary, although that won't get
you any efficiency improvements.

How many elements are you likely to have in here? In many cases any
resource usage improvement will be negligible.

We are not currently using 3.5--not sure if we need VS2008 to get
there? If so, we probably can't do so on this project; if not, then
it might be worth it if these Hashsets would make a big difference.

There will be a number of these collections in the system, of varying
sizes. The biggest ones may have at most 100K items in the list, with
(probably) a max of 20 lists of this size. The rest of the lists will
be small, probably no more than a few hundred items.

Thanks for your response.

Phil

[Jon Skeet [C# MVP]]

Phil Sandler <ps********@hotmail.comwrote:

How many elements are you likely to have in here? In many cases any
resource usage improvement will be negligible.

We are not currently using 3.5--not sure if we need VS2008 to get
there? If so, we probably can't do so on this project; if not, then
it might be worth it if these Hashsets would make a big difference.

Yes, you need VS2008 to use .NET 3.5. Of course, there are other big
reasons for using VS2008 - all the goodness of C# 3, for one thing.

I do understand the need to not change technologies mid-project,
however.

There will be a number of these collections in the system, of varying
sizes. The biggest ones may have at most 100K items in the list, with
(probably) a max of 20 lists of this size. The rest of the lists will
be small, probably no more than a few hundred items.

Well, do a test - but I doubt it will cost you vast amounts of
resources.

You may well find there are free 3rd party implementations around.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com