Using "fscan" Equivalent in C#

[marathoner]

I would like to read the following entries of mixed data types from a ascii
text file using C#. This can be easily performed in C using fscanf. Is
there an equivalent function in C#?
1 2 1201 1 -0.4175970000000 00D+06 0.1296000000000 00D+06
0.0 0.7530000000000 00D+03 0.1988000000000 00D+04
Marathoner

[jehugaleahsa]

On Nov 27, 8:30 am, "Jon Skeet [C# MVP]" <[e-mail] mwrote:

On Nov 27, 3:14 pm, "marathoner " <rajk2...@msn.c om.invalidwrote :

How would you use regular expression?

Use the regex to capture the appropriate groups (if it's not as simple
as just splitting by a common delimiter - if it is, that's fine) and
then int.Parse etc to convert those group values into the types you
need.

If you can get away with just using string.Split and then parsing each
part separately, so much the better :)

Jon

The fact is that working with operator >in C++ was facinatingly easy
for beginning programmers. I have worked with both philosophies for a
long while each. I prefer >simply because it says a lot more with
less code. However, most programmers don't have the time or the
training to fully understand >overloading for their custom types. C+
+ programmers see reading an entire line as a bit like filling your
mouth with more than you can chew. I have always felt like I am taking
more than I need up-front and then breaking it into pieces and then
converting all the pieces to the right type and then finally using
them for their intended purpose. A lot of input isn't that
complicated, in general.

However, in light of things, input is rare. If you are reading data
files, then usually there is a set format and it is usually separated
by lines anyway. Regex and Int32.Parse is a lot more manual but a lot
more safe. >will fail to read something and go on tra-la-la-ing.
scanf's are just plain type-unsafe and hard for most people to
understand. It is possible for C++ IO to throw errors on bad data
reads, however, it is an advanced topic. The one failure of the C++ IO
is its complexity. I believe it can be learned by buying a good book
on the STL, however, it isn't something you are going to retain
overnight. The .NET IO classes are very intuitive and work well
together.

There is no law against pulling in input characters-at-a-time and
converting them to numbers manually. fscanf is really just a big if-
else inside a loop - anyone could write a trimmed-down version. I like
C#'s method and I like C++'s method. A lot of research, history and
ingenuity went into both of them and they should be respected by
anyone who appreciates good code. It's really not a matter of which
way's best or which way is sufficient. It is a matter of changing
philosophies.

[Jon Skeet [C# MVP]]

je**********@gm ail.com <je**********@g mail.comwrote:

How would you use regular expression?

Use the regex to capture the appropriate groups (if it's not as simple
as just splitting by a common delimiter - if it is, that's fine) and
then int.Parse etc to convert those group values into the types you
need.

If you can get away with just using string.Split and then parsing each
part separately, so much the better :)

The fact is that working with operator >in C++ was facinatingly easy
for beginning programmers.

It's still an abuse of operator overloading, IMO.

I have worked with both philosophies for a
long while each. I prefer >simply because it says a lot more with
less code.

You could say a lot with little code by naming methods "A" and "B"
instead, too - it wouldn't be a good idea. >is defined in the
language spec to be a bit shifting operation, which reading data from a
stream certainly isn't. I'm really glad C# hasn't gone this route.

However, most programmers don't have the time or the
training to fully understand >overloading for their custom types. C+
+ programmers see reading an entire line as a bit like filling your
mouth with more than you can chew. I have always felt like I am taking
more than I need up-front and then breaking it into pieces and then
converting all the pieces to the right type and then finally using
them for their intended purpose. A lot of input isn't that
complicated, in general.

On the other hand, it's usually more efficient to grab a whole buffer's
worth of data and then process it, than to request one byte at a time
from the input stream.

However, in light of things, input is rare. If you are reading data
files, then usually there is a set format and it is usually separated
by lines anyway. Regex and Int32.Parse is a lot more manual but a lot
more safe. >will fail to read something and go on tra-la-la-ing.
scanf's are just plain type-unsafe and hard for most people to
understand.

Indeed.

It is possible for C++ IO to throw errors on bad data
reads, however, it is an advanced topic. The one failure of the C++ IO
is its complexity. I believe it can be learned by buying a good book
on the STL, however, it isn't something you are going to retain
overnight. The .NET IO classes are very intuitive and work well
together.

Yes, in general .NET has been very well designed - it's learned lessons
from C++ and Java. It's a shame that it didn't get date+time support
right to start with; I believe it's a lot better in 3.5 but I haven't
looked in detail.

There is no law against pulling in input characters-at-a-time and
converting them to numbers manually. fscanf is really just a big if-
else inside a loop - anyone could write a trimmed-down version. I like
C#'s method and I like C++'s method. A lot of research, history and
ingenuity went into both of them and they should be respected by
anyone who appreciates good code. It's really not a matter of which
way's best or which way is sufficient. It is a matter of changing
philosophies.

True. I still object to the overloading of >on principle though :)
Having a *method* which you pass a format to is a reasonable idea.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Ben Voigt [C++ MVP]]

"KWienhold" <he******@trash mail.netwrote in message
news:7e******** *************** ***********@x69 g2000hsx.google groups.com...

On 27 Nov., 05:05, "jehugalea...@g mail.com" <jehugalea...@g mail.com>
wrote:

>On Nov 26, 8:54 pm, Lev Elbert <elbert...@hotm ail.comwrote:

//You need to read the line and use pattern matching to parse line on
types

wouldn't' it be good if such task could be done simpler?

People who have been around C and C++ who know about the wonders of >>
operators and scanfs find it hard to believe there is not a similar,
easy facility in Java and C#. There are a lot of small projects that
simulate it as best as possible. I would recommend a search on
CodeProject.

Actually, C# does have bit-shifting, even using the same operator ;)

I hope that your wink indicates <sarcasm></sarcasmaround your post.

But it turns out that C# can overload << and >just fine.

>
Kevin Wienhold

[KWienhold]

On 29 Nov., 18:54, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

"KWienhold" <hedov...@trash mail.netwrote in message

news:7e******** *************** ***********@x69 g2000hsx.google groups.com...

On 27 Nov., 05:05, "jehugalea...@g mail.com" <jehugalea...@g mail.com>
wrote:

On Nov 26, 8:54 pm, Lev Elbert <elbert...@hotm ail.comwrote:

//You need to read the line and use pattern matching to parse line on
types

wouldn't' it be good if such task could be done simpler?

People who have been around C and C++ who know about the wonders of >>
operators and scanfs find it hard to believe there is not a similar,
easy facility in Java and C#. There are a lot of small projects that
simulate it as best as possible. I would recommend a search on
CodeProject.

Actually, C# does have bit-shifting, even using the same operator ;)

I hope that your wink indicates <sarcasm></sarcasmaround your post.

But it turns out that C# can overload << and >just fine.

Kevin Wienhold- Zitierten Text ausblenden -

- Zitierten Text anzeigen -- Zitierten Text ausblenden -

- Zitierten Text anzeigen -

Yeah, it was supposed to be humerous, in retrospect, it probably
wasn't ;)

Kevin Wienhold