StringCollection and StringDictionary

[Tony Johansson]

Hi!

There are two collection class named StringCollection and StringDictionary
that are obolete now when generics can be used.
I just want to get it confirmed that my assumtions is correct.

So are these two identical StringCollection and the generic List<string>.
and
is StringDictionary and the generic Dictionary<string,string>

//Tony

 

[Jeroen Mostert]

There are two collection class named StringCollection and StringDictionary
that are obolete now when generics can be used.
I just want to get it confirmed that my assumtions is correct.

They're not literally obsolete in that they're not marked [Obsolete] in the
framework itself, but there's no need to use them in new classes.

So are these two identical StringCollection and the generic List<string>.

Functionally equivalent, yes.

is StringDictionary and the generic Dictionary<string,string>

StringDictionary translates its keys to lowercase before they're added.
Dictionary<> always leaves its keys intact, but you can pass a
case-insensitive string comparer that will make it treat keys that differ
only in case as equal (it will still retain case).

 

[Family Tree Mike]

Hi!

There are two collection class named StringCollection and StringDictionary
that are obolete now when generics can be used.
I just want to get it confirmed that my assumtions is correct.

So are these two identical StringCollection and the generic List<string>.
and
is StringDictionary and the generic Dictionary<string,string>

//Tony

"Obsolete" has a specific meaning in code, which is not true of these
two classes. They are not marked as obsolete, from what I can see. The
generics may be "preferred" in some ways however.

There is at least on difference between StringDictionary and
Dictionary<string, string>, which is that the generic implimentation
constructor allows for a IEqualityComparer to be specified.
StringDictionary does not allow for this in a constructor.

 

[Peter Duniho]

[...]
StringDictionary translates its keys to lowercase before they're added.

And IMHO, this makes the class one to be avoided, due to the fact that
translating to lower-case is not actually a uniformly reliable way to
implement case-insensitive comparisons.

Dictionary<> always leaves its keys intact, but you can pass a
case-insensitive string comparer that will make it treat keys that
differ only in case as equal (it will still retain case).

Note also that because Dictionary<TKey, TValue> isn't rewriting the
keys, that reduces execution _and_ memory allocation overhead during
element additions.

IMHO, there are enough problems with StringDictionary that I think they
might as well have marked it obsolete.

Pete

 

[Kenneth Cochran]

Hi!

There are two collection class named StringCollection and StringDictionary
that are obolete now when generics can be used.
I just want to get it confirmed that my assumtions is correct.

So are these two identical StringCollection and the generic List<string>.
and
is StringDictionary and the generic Dictionary<string,string>

//Tony

Generic collections offer more functionality than the non-generic
collections. List<T> has overloaded methods that support Action<T> and
Predicate<T> delegates. Additionally, they are faster for most
operations. A StringCollection is implemented as a wrapper for an
ArrayList so there is a hidden overhead of box/unboxing.

 

[Peter Duniho]

Generic collections offer more functionality than the non-generic
collections.

This is often true. But IMHO the real advantages to generic types are
the ability to write strongly-typed code, and the ability to avoid
boxing of value types (which would be required in any general-purpose
class based on System.Object instead of being a generic type).

The added features are mostly just "icing on the cake".

List<T> has overloaded methods that support Action<T> and
Predicate<T> delegates.

Actually, List<T> has no overloaded method that uses Action<T>. And in
fact, the only overloaded methods that use Predicate<T> are FindIndex()
and FindLastIndex(), and the fact that they are overloaded really has

Additionally, they are faster for most
operations. A StringCollection is implemented as a wrapper for an
ArrayList so there is a hidden overhead of box/unboxing.

That's not true. A StringCollection contains instances of
System.String, a reference type, and so when stored in an ArrayList
there is no boxing necessary. There is a minor overhead when retrieving
items, due to the type check required during the casting from
System.Object to System.String, but it's highly unlikely any real-world
code, where the objects are actually being used, would be affected by
that effect.

There should be no practical difference in performance between
List<System.String> and System.Collections.Specialized.StringCollection.

Pete

 

[Kenneth Cochran]

This is often true. But IMHO the real advantages to generic types are
the ability to write strongly-typed code, and the ability to avoid
boxing of value types (which would be required in any general-purpose
class based on System.Object instead of being a generic type).

The added features are mostly just "icing on the cake".

I agree. I was simply answering the question asked.

Actually, List<T> has no overloaded method that uses Action<T>. And in
fact, the only overloaded methods that use Predicate<T> are FindIndex()
and FindLastIndex(), and the fact that they are overloaded really has
nothing to do with the fact that they accept a Predicate<T>. The
overloads are there to support sub-ranges for the searches.

My point wasn't the number of overloaded methods List<T> has. My point
was that it supports Actions and Predicates which are more concise than
interating over a collection in a foreach loop.

That's not true. A StringCollection contains instances of System.String,
a reference type, and so when stored in an ArrayList there is no boxing
necessary. There is a minor overhead when retrieving items, due to the
type check required during the casting from System.Object to
System.String, but it's highly unlikely any real-world code, where the
objects are actually being used, would be affected by that effect.

True, I had forgotten String is a reference type. Box/UnBoxing not
withstanding, the combined overhead of the additional call to
ArrayList's methods and casting is enough to consider StringCollection
less efficient than List<String>. In principle, this isn't enough to
choose one over the other unless it is causing a performance problem.
But as you pointed out, this is unlikely to be a factor in most
real-world uses.