views:

157

answers:

3

I want to hold about 30 strings in a static "collection". I then need to check the path of an incoming web request against this list.

I was thinking of using a StringDictionary with the Key and the Value having the the same values. However it just seems odd when all I really want is a key look up, so I can check for existence rather than look up a value to use.

Am I worrying about nothing?

Pat

+4  A: 

If you just need a key lookup to check for existence, use a Set instead.

Eric Petroelje
+8  A: 

What language are you using?

.NET supports Hashset<>, which fits what you're describing.

teedyay
I am using C#\.NET 3.5. I had never even heard of HashSet<>, thanks
Pat Long - Munkii Yebee
+4  A: 

I agree with the comments about this being what a set is for - but it's also the case that prior to version 3.5, .NET didn't have a set type. The closest you could easily get (using just the built-in libraries and not writing your own set) was a dictionary where the value is irrelevant.

However, I wonder whether for just 30 strings in .NET earlier than 3.5, a List<string> might not be the ticket. We know that hashsets work really well for big sets, but if you know you're using a small set of strings, a simple List<string>.Contains call will be fairly quick. String.Equals can check lengths to start with, and then check each character so it's probably going to reject non-matches very quickly.

In short, I'd probably use HashSet<string> if you're using .NET 3.5, List<string> if you're using .NET 2.0 or 3.0, and possibly ArrayList if you're using .NET 1.1. That should give the simplest possible calling code, and the performance is likely to be fine. If you believe it's becoming a bottleneck, prove it with a profiler.

Jon Skeet