string[] to int[]

[Andrew Robinson]

I have an array of string that I need to convert to an array of int. Any
elegant method other than iterating through it and using int.parse() on each
element?

Thanks,

 

[Peter Rilling]

No.

 

[Andrew Robinson]

Going to answer my own question here:

string[] input = { "1", "2", "3", "4", "5", "6", "7", "8", "9" };

int[] output = Array.ConvertAll<string, int>(input, delegate(string s) {
return int.Parse(s); });

 

[Stephany Young]

Did you read the part in the documentation for Array.ConvertAll where it
states:

The elements of array are individually passed
to the Converter, and the converted elements
are saved in the new array.

If that's not iteration then I don't know what is.

Going to answer my own question here:

string[] input = { "1", "2", "3", "4", "5", "6", "7", "8", "9" };

int[] output = Array.ConvertAll<string, int>(input, delegate(string s) {
return int.Parse(s); });

I have an array of string that I need to convert to an array of int. Any
elegant method other than iterating through it and using int.parse() on
each element?

Thanks,

 

[Andrew Robinson]

I guess it is when you get right down to it.

-A

Did you read the part in the documentation for Array.ConvertAll where it
states:

The elements of array are individually passed
to the Converter, and the converted elements
are saved in the new array.

If that's not iteration then I don't know what is.

Going to answer my own question here:

string[] input = { "1", "2", "3", "4", "5", "6", "7", "8", "9" };

int[] output = Array.ConvertAll<string, int>(input, delegate(string s)
{ return int.Parse(s); });

I have an array of string that I need to convert to an array of int. Any
elegant method other than iterating through it and using int.parse() on
each element?

Thanks,

 

[Scott C]

Did you read the part in the documentation for Array.ConvertAll where it
Yes, but I think the value of this kind of thing is that the OP doesn't
have to do the iterating himself. The mantra is "code reuse".

The elegant part of ConvertAll is that it does what you want and you
don't have to write any code.

my 2 cents

Scott

 

[Stephany Young]

Agreed. However, from my point of view, the important thing is control over
what is happening.

Take a modified example of Andrew's example where one or more elements of
the string array have values that will fail an int.Parse operation.

All one gets is an exception with no information as to which element is at
fault. One then would still have to iterate 'manually' through the array to
determine which element or elements are invalid.

If one converts the string array by iteration 'manually', then one has the
opportunity to 'catch and report' any elements that will fail the
conversion.

Although there are a lot of what I call 'code savers' that are very useful,
one has to be circumspect when using them so that one avoids unintended
consequences.

 

[Marc Gravell]

I'm not sure it's that different either way; in the anonymous delegate you
would still have access to e.g. any error collection etc that is scoped by
the containing method, or any class members like events.

Because of this, in a scenario like this the only thing that would make me
choose one over the other is performance; I remember a chain a little while
ago (here) comparing foreach, ForEach and indexer based access :
embarrasingly I can't remember which one won ;-(

Marc

 

[=?iso-8859-1?Q?Lasse=20V=e5gs=e6ther=20Karlsen?=]

I'm not sure it's that different either way; in the anonymous delegate

you would still have access to e.g. any error collection etc that is
scoped by the containing method, or any class members like events.

Because of this, in a scenario like this the only thing that would
make me choose one over the other is performance; I remember a chain a
little while ago (here) comparing foreach, ForEach and indexer based
access : embarrasingly I can't remember which one won ;-(

Marc

The article taking on ForEach, indexer, etc. is found here:

http://msmvps.com/blogs/jon.skeet/archive/2006/01/20/foreachperf.aspx

 

[Jon Skeet [C# MVP]]

I'm not sure it's that different either way; in the anonymous delegate you
would still have access to e.g. any error collection etc that is scoped by
the containing method, or any class members like events.

I was thinking about that - and there's *one* difference which springs
to mind. If you use a plain for loop with an index, you get to know the
*indexes* of which elements are invalid (or whatever). If you use
foreach or the collection methods, you only get to know the *values*.
Sometimes the indexes could be important (eg to highlight invalid rows
in a UI).

Because of this, in a scenario like this the only thing that would make me
choose one over the other is performance; I remember a chain a little while
ago (here) comparing foreach, ForEach and indexer based access :
embarrasingly I can't remember which one won ;-(

See
http://msmvps.com/blogs/jon.skeet/archive/2006/01/20/foreachperf.aspx

I would expect even the reasonably cheap operation of parsing integers
to dwarf the iteration performance.

Unless you have a good reason to believe that performance is
particularly important in a given situation, it's one of the *last*
reasons I would use to choose one over the other. I'd go for simplicity
and readability primarily - and that will depend on what error handling
is required etc.

Jon

 

[Andrew Robinson]

Thanks for all the info. Never thought I would spark such an interesting
discussion. In my case, I am using this to read values out of a config file.
I prefer using a foreach over a for loop when ever I can.

The following is in need of exception handling but given all that I have
learned, I would choose this over a more "manual" approach.

<appSettings>
<add key="MachineIDs" value="44,3,43,566" />
</appSettings>

private int[] GetConfigIntArray(string key)
{
string[] values = ConfigurationManager.AppSettings[key].Split(',');
return Array.ConvertAll<string, int>(values, delegate(string s) { return
int.Parse(s); });
}
Thanks,
-Andrew