471,325 Members | 1,641 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,325 software developers and data experts.

string[] to int[]

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,
Feb 17 '06 #1
10 4101
No.

"Andrew Robinson" <ne****@nospam.nospam> wrote in message
news:uq**************@TK2MSFTNGP09.phx.gbl...
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,

Feb 17 '06 #2
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); });
"Andrew Robinson" <ne****@nospam.nospam> wrote in message
news:uq**************@TK2MSFTNGP09.phx.gbl...
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,

Feb 17 '06 #3
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.
"Andrew Robinson" <ne****@nospam.nospam> wrote in message
news:Of**************@TK2MSFTNGP12.phx.gbl...
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); });
"Andrew Robinson" <ne****@nospam.nospam> wrote in message
news:uq**************@TK2MSFTNGP09.phx.gbl...
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,


Feb 17 '06 #4
I guess it is when you get right down to it.

-A

"Stephany Young" <noone@localhost> wrote in message
news:O7**************@TK2MSFTNGP12.phx.gbl...
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.
"Andrew Robinson" <ne****@nospam.nospam> wrote in message
news:Of**************@TK2MSFTNGP12.phx.gbl...
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); });
"Andrew Robinson" <ne****@nospam.nospam> wrote in message
news:uq**************@TK2MSFTNGP09.phx.gbl...
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,



Feb 17 '06 #5
>>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.


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
Feb 17 '06 #6
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.
"Scott C" <sdcoonce@g_m_a_i_l.com> wrote in message
news:Op**************@TK2MSFTNGP12.phx.gbl...
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.


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

Feb 17 '06 #7
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
Feb 17 '06 #8
> 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/ar...reachperf.aspx

--
Lasse Vågsæther Karlsen
http://usinglvkblog.blogspot.com/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2
Feb 17 '06 #9
Marc Gravell wrote:
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/ar...reachperf.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

Feb 17 '06 #10
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

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
Marc Gravell wrote:
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/ar...reachperf.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

Feb 17 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

19 posts views Thread by Erik Wikström | last post: by
29 posts views Thread by zoro | last post: by
15 posts views Thread by Fariba | last post: by
1 post views Thread by fakeprogress | last post: by
15 posts views Thread by morleyc | last post: by
3 posts views Thread by jacob navia | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.