AddRange to a Collection
up vote
83
down vote
favorite
A coworker asked me today how to add a range to a collection. He has a class that inherits from Collection<T>
. There's a get-only property of that type that already contains some items. He wants to add the items in another collection to the property collection. How can he do so in a C#3-friendly fashion? (Note the constraint about the get-only property, which prevents solutions like doing Union and reassigning.)
Sure, a foreach with Property. Add will work. But a List<T>
-style AddRange would be far more elegant.
It's easy enough to write an extension method:
public static class CollectionHelpers
{
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
foreach (T item in source)
{
destination.Add(item);
}
}
}
But I have the feeling I'm reinventing the wheel. I didn't find anything similar in System.Linq
or morelinq.
Bad design? Just Call Add? Missing the obvious?
c# collections c#-3.0 extension-methods
add a comment |
up vote
83
down vote
favorite
A coworker asked me today how to add a range to a collection. He has a class that inherits from Collection<T>
. There's a get-only property of that type that already contains some items. He wants to add the items in another collection to the property collection. How can he do so in a C#3-friendly fashion? (Note the constraint about the get-only property, which prevents solutions like doing Union and reassigning.)
Sure, a foreach with Property. Add will work. But a List<T>
-style AddRange would be far more elegant.
It's easy enough to write an extension method:
public static class CollectionHelpers
{
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
foreach (T item in source)
{
destination.Add(item);
}
}
}
But I have the feeling I'm reinventing the wheel. I didn't find anything similar in System.Linq
or morelinq.
Bad design? Just Call Add? Missing the obvious?
c# collections c#-3.0 extension-methods
3
Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
– Levi
Sep 25 '09 at 0:46
One problem,ICollection<T>
does not seem to have anAdd
method. msdn.microsoft.com/en-us/library/… HoweverCollection<T>
has one.
– Tim Goodman
Jul 11 '13 at 5:58
@TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
– TrueWill
Jul 11 '13 at 17:26
add a comment |
up vote
83
down vote
favorite
up vote
83
down vote
favorite
A coworker asked me today how to add a range to a collection. He has a class that inherits from Collection<T>
. There's a get-only property of that type that already contains some items. He wants to add the items in another collection to the property collection. How can he do so in a C#3-friendly fashion? (Note the constraint about the get-only property, which prevents solutions like doing Union and reassigning.)
Sure, a foreach with Property. Add will work. But a List<T>
-style AddRange would be far more elegant.
It's easy enough to write an extension method:
public static class CollectionHelpers
{
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
foreach (T item in source)
{
destination.Add(item);
}
}
}
But I have the feeling I'm reinventing the wheel. I didn't find anything similar in System.Linq
or morelinq.
Bad design? Just Call Add? Missing the obvious?
c# collections c#-3.0 extension-methods
A coworker asked me today how to add a range to a collection. He has a class that inherits from Collection<T>
. There's a get-only property of that type that already contains some items. He wants to add the items in another collection to the property collection. How can he do so in a C#3-friendly fashion? (Note the constraint about the get-only property, which prevents solutions like doing Union and reassigning.)
Sure, a foreach with Property. Add will work. But a List<T>
-style AddRange would be far more elegant.
It's easy enough to write an extension method:
public static class CollectionHelpers
{
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
foreach (T item in source)
{
destination.Add(item);
}
}
}
But I have the feeling I'm reinventing the wheel. I didn't find anything similar in System.Linq
or morelinq.
Bad design? Just Call Add? Missing the obvious?
c# collections c#-3.0 extension-methods
c# collections c#-3.0 extension-methods
edited Jul 5 '16 at 18:22
Juan Castillo
3,42732535
3,42732535
asked Sep 25 '09 at 0:33
TrueWill
19.5k673120
19.5k673120
3
Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
– Levi
Sep 25 '09 at 0:46
One problem,ICollection<T>
does not seem to have anAdd
method. msdn.microsoft.com/en-us/library/… HoweverCollection<T>
has one.
– Tim Goodman
Jul 11 '13 at 5:58
@TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
– TrueWill
Jul 11 '13 at 17:26
add a comment |
3
Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
– Levi
Sep 25 '09 at 0:46
One problem,ICollection<T>
does not seem to have anAdd
method. msdn.microsoft.com/en-us/library/… HoweverCollection<T>
has one.
– Tim Goodman
Jul 11 '13 at 5:58
@TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
– TrueWill
Jul 11 '13 at 17:26
3
3
Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
– Levi
Sep 25 '09 at 0:46
Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
– Levi
Sep 25 '09 at 0:46
One problem,
ICollection<T>
does not seem to have an Add
method. msdn.microsoft.com/en-us/library/… However Collection<T>
has one.– Tim Goodman
Jul 11 '13 at 5:58
One problem,
ICollection<T>
does not seem to have an Add
method. msdn.microsoft.com/en-us/library/… However Collection<T>
has one.– Tim Goodman
Jul 11 '13 at 5:58
@TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
– TrueWill
Jul 11 '13 at 17:26
@TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
– TrueWill
Jul 11 '13 at 17:26
add a comment |
7 Answers
7
active
oldest
votes
up vote
48
down vote
accepted
No, this seems perfectly reasonable. There is a List<T>.
AddRange() method that basically does just this, but requires your collection to be a concrete List<T>
.
Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
– TrueWill
Sep 25 '09 at 0:52
4
Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
– Reed Copsey
Sep 25 '09 at 1:12
add a comment |
up vote
29
down vote
Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
List<T> list = destination as List<T>;
if (list != null)
{
list.AddRange(source);
}
else
{
foreach (T item in source)
{
destination.Add(item);
}
}
}
2
Theas
operator will never throw. Ifdestination
cannot be cast,list
will be null and theelse
block will execute.
– rymdsmurf
Oct 29 '14 at 12:04
3
arrgggh! Swap the condition branches, for the love of all that's holy!
– nicodemus13
Jul 15 '16 at 16:11
9
I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
– nicodemus13
Jul 20 '16 at 7:42
9
Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
– rymdsmurf
Jul 25 '16 at 9:39
3
Pattern matching will make everyone happy... ;-)if (destination is List<T> list)
– Jacob Foshee
Sep 1 '17 at 21:47
|
show 2 more comments
up vote
19
down vote
Since .NET4.5
if you want one-liner you can use System.Collections.Generic
ForEach.
source.ForEach(o => destination.Add(o));
or even shorter as
source.ForEach(destination.Add);
Performance-wise it's same as for each loop (syntactic sugar).
Also don't try assigning it like
var x = source.ForEach(destination.Add)
cause ForEach
is void.
7
Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
– TrueWill
Jan 15 '15 at 16:21
1
Should it be source.ForEach(destination.Add) ?
– Frank
Sep 8 '16 at 20:04
@Frank Hi Frank, fixed thanks for noticing :)
– Matas Vaitkevicius
Sep 9 '16 at 6:30
1
ForEach
seems to only be defined onList<T>
, notCollection
?
– Protector one
Jul 13 at 12:09
add a comment |
up vote
18
down vote
Remember that each Add
will check the capacity of the collection and resize it whenever necessary (slower). With AddRange
, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.
3
To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
– Nick Udell
Sep 22 '14 at 9:58
add a comment |
up vote
1
down vote
The C5 Generic Collections Library classes all support the AddRange
method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic
ICollection
and IList
interfaces, meaning that C5
's collections can be easily substituted as the underlying implementation.
add a comment |
up vote
0
down vote
You could add your IEnumerable range to a list then set the ICollection = to the list.
IEnumerable<T> source;
List<item> list = new List<item>();
list.AddRange(source);
ICollection<item> destination = list;
3
While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
– Nick Udell
Sep 22 '14 at 9:56
add a comment |
up vote
0
down vote
Or you can just make an ICollection extension like this:
public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
{
foreach(var item in items)
{
@this.Add(item);
}
return @this;
}
Using it would be just like using it on a list:
collectionA.AddRange(IEnumerable<object> items);
add a comment |
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
48
down vote
accepted
No, this seems perfectly reasonable. There is a List<T>.
AddRange() method that basically does just this, but requires your collection to be a concrete List<T>
.
Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
– TrueWill
Sep 25 '09 at 0:52
4
Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
– Reed Copsey
Sep 25 '09 at 1:12
add a comment |
up vote
48
down vote
accepted
No, this seems perfectly reasonable. There is a List<T>.
AddRange() method that basically does just this, but requires your collection to be a concrete List<T>
.
Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
– TrueWill
Sep 25 '09 at 0:52
4
Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
– Reed Copsey
Sep 25 '09 at 1:12
add a comment |
up vote
48
down vote
accepted
up vote
48
down vote
accepted
No, this seems perfectly reasonable. There is a List<T>.
AddRange() method that basically does just this, but requires your collection to be a concrete List<T>
.
No, this seems perfectly reasonable. There is a List<T>.
AddRange() method that basically does just this, but requires your collection to be a concrete List<T>
.
answered Sep 25 '09 at 0:40
Reed Copsey
463k579651268
463k579651268
Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
– TrueWill
Sep 25 '09 at 0:52
4
Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
– Reed Copsey
Sep 25 '09 at 1:12
add a comment |
Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
– TrueWill
Sep 25 '09 at 0:52
4
Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
– Reed Copsey
Sep 25 '09 at 1:12
Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
– TrueWill
Sep 25 '09 at 0:52
Thanks; very true, but most public properties follow the MS guidelines and are not Lists.
– TrueWill
Sep 25 '09 at 0:52
4
4
Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
– Reed Copsey
Sep 25 '09 at 1:12
Yeah - I was giving it more as rationale for why I don't think there is a problem with doing this. Just realize it will be less efficient than the List<T> version (since the list<T> can pre-allocate)
– Reed Copsey
Sep 25 '09 at 1:12
add a comment |
up vote
29
down vote
Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
List<T> list = destination as List<T>;
if (list != null)
{
list.AddRange(source);
}
else
{
foreach (T item in source)
{
destination.Add(item);
}
}
}
2
Theas
operator will never throw. Ifdestination
cannot be cast,list
will be null and theelse
block will execute.
– rymdsmurf
Oct 29 '14 at 12:04
3
arrgggh! Swap the condition branches, for the love of all that's holy!
– nicodemus13
Jul 15 '16 at 16:11
9
I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
– nicodemus13
Jul 20 '16 at 7:42
9
Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
– rymdsmurf
Jul 25 '16 at 9:39
3
Pattern matching will make everyone happy... ;-)if (destination is List<T> list)
– Jacob Foshee
Sep 1 '17 at 21:47
|
show 2 more comments
up vote
29
down vote
Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
List<T> list = destination as List<T>;
if (list != null)
{
list.AddRange(source);
}
else
{
foreach (T item in source)
{
destination.Add(item);
}
}
}
2
Theas
operator will never throw. Ifdestination
cannot be cast,list
will be null and theelse
block will execute.
– rymdsmurf
Oct 29 '14 at 12:04
3
arrgggh! Swap the condition branches, for the love of all that's holy!
– nicodemus13
Jul 15 '16 at 16:11
9
I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
– nicodemus13
Jul 20 '16 at 7:42
9
Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
– rymdsmurf
Jul 25 '16 at 9:39
3
Pattern matching will make everyone happy... ;-)if (destination is List<T> list)
– Jacob Foshee
Sep 1 '17 at 21:47
|
show 2 more comments
up vote
29
down vote
up vote
29
down vote
Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
List<T> list = destination as List<T>;
if (list != null)
{
list.AddRange(source);
}
else
{
foreach (T item in source)
{
destination.Add(item);
}
}
}
Try casting to List in the extension method before running the loop. That way you can take advantage of the performance of List.AddRange.
public static void AddRange<T>(this ICollection<T> destination,
IEnumerable<T> source)
{
List<T> list = destination as List<T>;
if (list != null)
{
list.AddRange(source);
}
else
{
foreach (T item in source)
{
destination.Add(item);
}
}
}
edited Oct 14 '14 at 14:20
TrueWill
19.5k673120
19.5k673120
answered Oct 14 '14 at 11:44
rymdsmurf
450410
450410
2
Theas
operator will never throw. Ifdestination
cannot be cast,list
will be null and theelse
block will execute.
– rymdsmurf
Oct 29 '14 at 12:04
3
arrgggh! Swap the condition branches, for the love of all that's holy!
– nicodemus13
Jul 15 '16 at 16:11
9
I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
– nicodemus13
Jul 20 '16 at 7:42
9
Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
– rymdsmurf
Jul 25 '16 at 9:39
3
Pattern matching will make everyone happy... ;-)if (destination is List<T> list)
– Jacob Foshee
Sep 1 '17 at 21:47
|
show 2 more comments
2
Theas
operator will never throw. Ifdestination
cannot be cast,list
will be null and theelse
block will execute.
– rymdsmurf
Oct 29 '14 at 12:04
3
arrgggh! Swap the condition branches, for the love of all that's holy!
– nicodemus13
Jul 15 '16 at 16:11
9
I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
– nicodemus13
Jul 20 '16 at 7:42
9
Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
– rymdsmurf
Jul 25 '16 at 9:39
3
Pattern matching will make everyone happy... ;-)if (destination is List<T> list)
– Jacob Foshee
Sep 1 '17 at 21:47
2
2
The
as
operator will never throw. If destination
cannot be cast, list
will be null and the else
block will execute.– rymdsmurf
Oct 29 '14 at 12:04
The
as
operator will never throw. If destination
cannot be cast, list
will be null and the else
block will execute.– rymdsmurf
Oct 29 '14 at 12:04
3
3
arrgggh! Swap the condition branches, for the love of all that's holy!
– nicodemus13
Jul 15 '16 at 16:11
arrgggh! Swap the condition branches, for the love of all that's holy!
– nicodemus13
Jul 15 '16 at 16:11
9
9
I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
– nicodemus13
Jul 20 '16 at 7:42
I am serious, actually.The main reason is that it's extra cognitive-load, which is often really quite difficult. You're constantly trying to evaluate negative conditions, which is usually relatively hard, you have both branches anyway, it's (IMO) easier to say 'if null' do this, 'else' do this, rather than the opposite. It's also about defaults, they should be the positive concept as often as possible, .e.g `if (!thing.IsDisabled) {} else {}' requires you to stop and think 'ah, not is disabled means is enabled, right, got that, so the other branch is when it IS disabled). Hard to parse.
– nicodemus13
Jul 20 '16 at 7:42
9
9
Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
– rymdsmurf
Jul 25 '16 at 9:39
Interpreting "something != null" is not more difficult than interpreting "something == null". The negation operator however is a completely different thing, and in your last example rewriting the if-else-statement would elliminate that operator. That is a objectively an improvement, but one that is not related to the original question. In that particular case the two forms are a matter of personal preferences, and I would prefer the "!="-operator, given the reasoning above.
– rymdsmurf
Jul 25 '16 at 9:39
3
3
Pattern matching will make everyone happy... ;-)
if (destination is List<T> list)
– Jacob Foshee
Sep 1 '17 at 21:47
Pattern matching will make everyone happy... ;-)
if (destination is List<T> list)
– Jacob Foshee
Sep 1 '17 at 21:47
|
show 2 more comments
up vote
19
down vote
Since .NET4.5
if you want one-liner you can use System.Collections.Generic
ForEach.
source.ForEach(o => destination.Add(o));
or even shorter as
source.ForEach(destination.Add);
Performance-wise it's same as for each loop (syntactic sugar).
Also don't try assigning it like
var x = source.ForEach(destination.Add)
cause ForEach
is void.
7
Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
– TrueWill
Jan 15 '15 at 16:21
1
Should it be source.ForEach(destination.Add) ?
– Frank
Sep 8 '16 at 20:04
@Frank Hi Frank, fixed thanks for noticing :)
– Matas Vaitkevicius
Sep 9 '16 at 6:30
1
ForEach
seems to only be defined onList<T>
, notCollection
?
– Protector one
Jul 13 at 12:09
add a comment |
up vote
19
down vote
Since .NET4.5
if you want one-liner you can use System.Collections.Generic
ForEach.
source.ForEach(o => destination.Add(o));
or even shorter as
source.ForEach(destination.Add);
Performance-wise it's same as for each loop (syntactic sugar).
Also don't try assigning it like
var x = source.ForEach(destination.Add)
cause ForEach
is void.
7
Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
– TrueWill
Jan 15 '15 at 16:21
1
Should it be source.ForEach(destination.Add) ?
– Frank
Sep 8 '16 at 20:04
@Frank Hi Frank, fixed thanks for noticing :)
– Matas Vaitkevicius
Sep 9 '16 at 6:30
1
ForEach
seems to only be defined onList<T>
, notCollection
?
– Protector one
Jul 13 at 12:09
add a comment |
up vote
19
down vote
up vote
19
down vote
Since .NET4.5
if you want one-liner you can use System.Collections.Generic
ForEach.
source.ForEach(o => destination.Add(o));
or even shorter as
source.ForEach(destination.Add);
Performance-wise it's same as for each loop (syntactic sugar).
Also don't try assigning it like
var x = source.ForEach(destination.Add)
cause ForEach
is void.
Since .NET4.5
if you want one-liner you can use System.Collections.Generic
ForEach.
source.ForEach(o => destination.Add(o));
or even shorter as
source.ForEach(destination.Add);
Performance-wise it's same as for each loop (syntactic sugar).
Also don't try assigning it like
var x = source.ForEach(destination.Add)
cause ForEach
is void.
edited Sep 9 '16 at 6:32
answered Jan 15 '15 at 15:17
Matas Vaitkevicius
32k15160170
32k15160170
7
Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
– TrueWill
Jan 15 '15 at 16:21
1
Should it be source.ForEach(destination.Add) ?
– Frank
Sep 8 '16 at 20:04
@Frank Hi Frank, fixed thanks for noticing :)
– Matas Vaitkevicius
Sep 9 '16 at 6:30
1
ForEach
seems to only be defined onList<T>
, notCollection
?
– Protector one
Jul 13 at 12:09
add a comment |
7
Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
– TrueWill
Jan 15 '15 at 16:21
1
Should it be source.ForEach(destination.Add) ?
– Frank
Sep 8 '16 at 20:04
@Frank Hi Frank, fixed thanks for noticing :)
– Matas Vaitkevicius
Sep 9 '16 at 6:30
1
ForEach
seems to only be defined onList<T>
, notCollection
?
– Protector one
Jul 13 at 12:09
7
7
Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
– TrueWill
Jan 15 '15 at 16:21
Personally I'm with Lippert on this one: blogs.msdn.com/b/ericlippert/archive/2009/05/18/…
– TrueWill
Jan 15 '15 at 16:21
1
1
Should it be source.ForEach(destination.Add) ?
– Frank
Sep 8 '16 at 20:04
Should it be source.ForEach(destination.Add) ?
– Frank
Sep 8 '16 at 20:04
@Frank Hi Frank, fixed thanks for noticing :)
– Matas Vaitkevicius
Sep 9 '16 at 6:30
@Frank Hi Frank, fixed thanks for noticing :)
– Matas Vaitkevicius
Sep 9 '16 at 6:30
1
1
ForEach
seems to only be defined on List<T>
, not Collection
?– Protector one
Jul 13 at 12:09
ForEach
seems to only be defined on List<T>
, not Collection
?– Protector one
Jul 13 at 12:09
add a comment |
up vote
18
down vote
Remember that each Add
will check the capacity of the collection and resize it whenever necessary (slower). With AddRange
, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.
3
To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
– Nick Udell
Sep 22 '14 at 9:58
add a comment |
up vote
18
down vote
Remember that each Add
will check the capacity of the collection and resize it whenever necessary (slower). With AddRange
, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.
3
To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
– Nick Udell
Sep 22 '14 at 9:58
add a comment |
up vote
18
down vote
up vote
18
down vote
Remember that each Add
will check the capacity of the collection and resize it whenever necessary (slower). With AddRange
, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.
Remember that each Add
will check the capacity of the collection and resize it whenever necessary (slower). With AddRange
, the collection will be set the capacity and then added the items (faster). This extension method will be extremely slow, but will work.
edited Oct 2 '12 at 10:30
jonsca
8,483114756
8,483114756
answered Aug 20 '12 at 14:50
jvitor83
308417
308417
3
To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
– Nick Udell
Sep 22 '14 at 9:58
add a comment |
3
To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
– Nick Udell
Sep 22 '14 at 9:58
3
3
To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
– Nick Udell
Sep 22 '14 at 9:58
To add to this, there will also be a collection change notification for each addition, as opposed to one bulk notification with AddRange.
– Nick Udell
Sep 22 '14 at 9:58
add a comment |
up vote
1
down vote
The C5 Generic Collections Library classes all support the AddRange
method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic
ICollection
and IList
interfaces, meaning that C5
's collections can be easily substituted as the underlying implementation.
add a comment |
up vote
1
down vote
The C5 Generic Collections Library classes all support the AddRange
method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic
ICollection
and IList
interfaces, meaning that C5
's collections can be easily substituted as the underlying implementation.
add a comment |
up vote
1
down vote
up vote
1
down vote
The C5 Generic Collections Library classes all support the AddRange
method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic
ICollection
and IList
interfaces, meaning that C5
's collections can be easily substituted as the underlying implementation.
The C5 Generic Collections Library classes all support the AddRange
method. C5 has a much more robust interface that actually exposes all of the features of its underlying implementations and is interface-compatible with the System.Collections.Generic
ICollection
and IList
interfaces, meaning that C5
's collections can be easily substituted as the underlying implementation.
answered Nov 5 '09 at 18:26
Marcus Griep
5,41211723
5,41211723
add a comment |
add a comment |
up vote
0
down vote
You could add your IEnumerable range to a list then set the ICollection = to the list.
IEnumerable<T> source;
List<item> list = new List<item>();
list.AddRange(source);
ICollection<item> destination = list;
3
While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
– Nick Udell
Sep 22 '14 at 9:56
add a comment |
up vote
0
down vote
You could add your IEnumerable range to a list then set the ICollection = to the list.
IEnumerable<T> source;
List<item> list = new List<item>();
list.AddRange(source);
ICollection<item> destination = list;
3
While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
– Nick Udell
Sep 22 '14 at 9:56
add a comment |
up vote
0
down vote
up vote
0
down vote
You could add your IEnumerable range to a list then set the ICollection = to the list.
IEnumerable<T> source;
List<item> list = new List<item>();
list.AddRange(source);
ICollection<item> destination = list;
You could add your IEnumerable range to a list then set the ICollection = to the list.
IEnumerable<T> source;
List<item> list = new List<item>();
list.AddRange(source);
ICollection<item> destination = list;
answered Aug 22 '14 at 5:49
Jonathan Jansen
1238
1238
3
While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
– Nick Udell
Sep 22 '14 at 9:56
add a comment |
3
While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
– Nick Udell
Sep 22 '14 at 9:56
3
3
While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
– Nick Udell
Sep 22 '14 at 9:56
While this functionally works, it breaks the Microsoft guidelines to make collection properties read only (msdn.microsoft.com/en-us/library/ms182327.aspx)
– Nick Udell
Sep 22 '14 at 9:56
add a comment |
up vote
0
down vote
Or you can just make an ICollection extension like this:
public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
{
foreach(var item in items)
{
@this.Add(item);
}
return @this;
}
Using it would be just like using it on a list:
collectionA.AddRange(IEnumerable<object> items);
add a comment |
up vote
0
down vote
Or you can just make an ICollection extension like this:
public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
{
foreach(var item in items)
{
@this.Add(item);
}
return @this;
}
Using it would be just like using it on a list:
collectionA.AddRange(IEnumerable<object> items);
add a comment |
up vote
0
down vote
up vote
0
down vote
Or you can just make an ICollection extension like this:
public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
{
foreach(var item in items)
{
@this.Add(item);
}
return @this;
}
Using it would be just like using it on a list:
collectionA.AddRange(IEnumerable<object> items);
Or you can just make an ICollection extension like this:
public static ICollection<T> AddRange<T>(this ICollection<T> @this, IEnumerable<T> items)
{
foreach(var item in items)
{
@this.Add(item);
}
return @this;
}
Using it would be just like using it on a list:
collectionA.AddRange(IEnumerable<object> items);
answered Nov 9 at 10:53
Katarina Kelam
11
11
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1474863%2faddrange-to-a-collection%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Remember that the Q from LINQ is 'query' and is really about data retrieval, projection, transformation, etc. Modifying existing collections really doesn't fall into the realm of LINQ's intended purpose, which is why LINQ doesn't provide anything out-of-the-box for this. But extension methods (and in particular your sample) would be ideal for this.
– Levi
Sep 25 '09 at 0:46
One problem,
ICollection<T>
does not seem to have anAdd
method. msdn.microsoft.com/en-us/library/… HoweverCollection<T>
has one.– Tim Goodman
Jul 11 '13 at 5:58
@TimGoodman - That's the non-generic interface. See msdn.microsoft.com/en-us/library/92t2ye13.aspx
– TrueWill
Jul 11 '13 at 17:26