Dictionary<> to List<>

[Andrew Robinson]

I have a method that needs to return either a Dictionary<k,v> or a List<v>
depending on input parameters and options to the method.

1. Is there any way to convert from a dictionary to a list without
itterating through the entire collection and building up a list?
2. is there a common base class, collection or interface that can contain
either/both of these collection types and then how do you convert or cast
from the base to either a dictionary or list?


thanks,

-Andy

 

[Andrew Robinson]

How efficient is this?

Dictionary<EntityKey, Entity> dictionary = new
Dictionary<EntityKey, Entity>();

// build the dictionary....

List<Entity> list = new List<Entity>(dictionary.Values);

 

[Christof Nordiek]

Hi Ronbinson

I have a method that needs to return either a Dictionary<k,v> or a List<v>
depending on input parameters and options to the method.

Why this has to be one method? The caller needs to know, what the method
returns, I'd suppose. So why not having to methods? Maybe an overload?

1. Is there any way to convert from a dictionary to a list without
itterating through the entire collection and building up a list?

No there isn't.

2. is there a common base class, collection or interface that can contain
either/both of these collection types and then how do you convert or cast
from the base to either a dictionary or list?

Well, they both implement ICollection and IEnumerable. But they would have
different Elementtypes (KeyValuePair<k,v> resp. v). And surely both
implement object ;-), but I don't think, that's what you want.

Christof

 

[Bobbo]

I have a method that needs to return either a Dictionary<k,v> or a List<v>
depending on input parameters and options to the method.

Dictionary.Values seems to behave in the same way as the List object,
e.g.

Dictionary<int, string> dict = new Dictionary<int,
string>();
foreach (string s in dict.Values)
{
}

List<string> list = new List<string>();
foreach (string s in list)
{
}

[I was about to post this and then spotted your own reply... If they
behave as ecpected, then I guess it does boil down to efficiency -
have you done some timings?]

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

How efficient is this?

Dictionary<EntityKey, Entity> dictionary = new
Dictionary<EntityKey, Entity>();

// build the dictionary....

List<Entity> list = new List<Entity>(dictionary.Values);

If it doesn't absolutely have to be a List<Entity>, you can use:

ValueCollection<Entity> list = dictionary.Values;

or:

ICollection<Entity> list = dictionary.Values;

or:

IEnumerable<Entity> list = dictionary.Values;


ValueCollection<T> implements both ICollection<T> and IEnumerable<T>.


If you want a list, the constructor of the list that takes the
collection will just copy the elements of the collection into a new
list. If Entity is a class, this means that it just copies the references.

 

[Andrew Robinson]

thanks,

-A

If it doesn't absolutely have to be a List<Entity>, you can use:

ValueCollection<Entity> list = dictionary.Values;

or:

ICollection<Entity> list = dictionary.Values;

or:

IEnumerable<Entity> list = dictionary.Values;


ValueCollection<T> implements both ICollection<T> and IEnumerable<T>.


If you want a list, the constructor of the list that takes the collection
will just copy the elements of the collection into a new list. If Entity
is a class, this means that it just copies the references.

 

[Samuel R. Neff]

Sounds like a nightmare to maintain if the method can return a
dictionary in on situation or a list in another. Why not create two
methods wich different names then it's much clearer?

The List based on can call the Dictionary one and ither return
ICollection from the values or create a List depending on your needs.

Sam

 

[Andrew Robinson]

Just an fyi to everyone: In the end, I created a method that takes a
delegate. Now you can create an anonymous method, pass it when you invoke
the method and create whatever collection type you want. Elegant solution!