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.417597000000000D+06 0.129600000000000D+06
0.0 0.753000000000000D+03 0.198800000000000D+04


Marathoner

 

[Michael Nemtsev]

No, there is not the same method as fscanf.
You need to read the line and use pattern matching to parse line on types

 

[Lev Elbert]

//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?

 

[jehugaleahsa]

//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.

 

[Jon Skeet [C# MVP]]

//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?

Is a regular expression + TextReader.ReadLine really so hard?

 

[KWienhold]

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

Kevin Wienhold

 

[Niels Ull]

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.417597000000000D+06
0.129600000000000D+06 0.0 0.753000000000000D+03
0.198800000000000D+04

If you're not too concerned about parse errors (e.g. willing to accept exceptions),
this could be done like this:

double[] numbers = Array.ConvertAll(RegEx.Split(line, "\\s+")), Double.Parse);

 

[Michael Nemtsev [MVP]]

Hello Jon Skeet [C# MVP],

It seems very crazy after F# pattern matching/active pattern features , isn't
it

---
WBR,
Michael Nemtsev [.NET/C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo


J> Is a regular expression + TextReader.ReadLine really so hard?
J>

 

[marathoner]

How would you use regular expression?

Marathoner

 

[Jon Skeet [C# MVP]]

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

 

[jehugaleahsa]

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]]

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.

 

[Ben Voigt [C++ MVP]]

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

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

 

[KWienhold]

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

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






- Zitierten Text anzeigen -- Zitierten Text ausblenden -

- Zitierten Text anzeigen -

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

Kevin Wienhold