What is the most basic class that inherits ICollection<T>

I need a generic collection class which I can add to, and enumerate over. Since ICollection<T> inherits from IEnumerable<T>, the class really just needs to inherit from ICollection<T>. Is there a simple generic class in the BCL that just inherits ICollection<T> like a generic version of CollectionBase? If not, then what class comes closest?

I would guess List<T> which is what I've been using but i don't need to sequential aspect. Is there anything better (by which I mean [smaller memory footprint/faster access/simpler])? Bag would be perfect if it existed.

EDIT 1: In my particular instance, I'm .concating to another IEnumerable, querying it, and then displaying the results (in no particular order). I'm not attempting to make my own class. I've just needed to make a throwaway collection so many times, that I thought it would be useful to find the best throwaway to use. Because I feel I've done something similar so many times, I felt I should keep this question as generic as possible (no pun intended), I know better now.

EDIT 2: Thanks for everybody's answers, As @BlueRaja pointed out, any simple class is going to have about the same overhead, and thus I think I will be sticking with my original ways of using List<T>. Since they are all about the same, my silly reasons of "It's easier to type", and "I don't have to bring in yet another using" aren't such bad reasons.

By default `Collection<T>` uses a `List<T>` as it's backing store so it's not smaller/faster than `List<T>` but exactly the opposite--it's an additional layer of abstraction (not that it would make a measurable difference).

Sam 2010-05-04 01:42:14

This might be of some relevance: http://stackoverflow.com/questions/426182/what-is-the-real-advantage-of-returning-icollectiont-instead-of-a-listt-clo

Igor Zevaka 2010-05-04 01:42:59

@Sam: By default, yes, but you can use anything as the backing store. That's why they introduced it; so you could design collection classes without having to concern yourself about what kind of backing storage is used, to avoid coupling yourself to a specific implementation.

Aaronaught 2010-05-04 01:44:23

@Igor: I don't really see how that link is relevant. That's about returning abstract interface types from methods instead of the internally-used concrete types.

Aaronaught 2010-05-04 01:45:12

Like @Sam said, `List<T>` is smaller. I'm not looking to subclass, only to hold a collection. It does seem strange that `Collection<T>` is larger than `List<T>`

Martin Neal 2010-05-04 01:52:05

@Martin: You and Sam are both missing the point; it's not about being "larger" or "smaller", the overhead is so minuscule that it's not going to make any difference in practice. What *will* make a difference is if you decide 3 months down the road that you picked an implementation that was inefficient for your particular usage pattern; if that happens, your life will be a lot easier if you used a more abstract type like `Collection<T>` than if you used a highly-specific type like `List<T>`. You should only pick `List<T>` if you know that it's optimal for your requirements.

Aaronaught 2010-05-04 01:57:47

Stick with List<T>. See the list and description in this link. I really dont think you have anything smaller than List<T> to pick from. http://msdn.microsoft.com/en-us/library/system.collections.generic(v=VS.80).aspx

Fadrian Sudaman 2010-05-04 02:04:35

Not to mention... your question literally asked if there was a "generic version of `CollectionBase`." Well, this is it. `CollectionBase` uses an `ArrayList` as its internal storage. `Collection<T>` uses `List<T>` by default, the generic equivalent of `ArrayList`. `Collection<T>` is, in all meaningful respects, the generic equivalent of `CollectionBase`. That is the answer to the question you asked.

Aaronaught 2010-05-04 02:05:26

@Martin, instead of using `Collection<T>` because it provides some abstraction it would be even better to program to the interfaces everywhere except when the collections are created, then it's trivial to choose a different implementation since everything else uses the interface.

Sam 2010-05-04 02:11:01

@Sam, yes, that's what I've been doing and is great advice, and my OP really meant to pertain to the trivial choice of implementation, which I'm realizing now that `List<T>` is as good as any.@Aaronaught, Thank-you for your answer, it truely was helpful even if not exactly what I needed. Indeed `Collection<T>` does seem the generic equivalent to `CollectionBase`. Had I known about `Collection<T>` I would have phrased my question a bit differently and placed more emphasis on only inheriting from ICollection<T>.

Martin Neal 2010-05-04 02:30:52

In my particular instance, I'm `concat`ing it onto another `IEnumerable`, querying that `IEnumerable` and displaying the output. `LinkedList<>` looks like it has even more structure than List.

Martin Neal 2010-05-04 01:47:09

@Martin: "more structure" does not mean "slower" or "greater memory footprint." Even if you have 1,000,000 items in each list, you will still only have **two** lists, so the memory-overhead of the lists themselves is not of great importance.

BlueRaja - Danny Pflughoeft 2010-05-04 01:53:57

@Martin Neal, those are the kind of details that would be helpful to include in the original question. :-)

Sam 2010-05-04 02:07:56

It's not really accurate to say they all have the same memory footprint. A linked list will use more memory than an array-based list. As you note, it definitely performs better for insertions and removals at the ends. This can apply in the middle too, if you already have a LinkedListNode pointer (sometimes regardless).

Matthew Flaschen 2010-05-04 02:51:51

ansaurus

tags:

views:

answers:

What is the most basic class that inherits ICollection<T>

related questions