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

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

Show quoteHide quote

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

On Nov 26, 8:54 pm, Lev Elbert <elbert***@hotmail.com> wrote:
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.

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

Kevin Wienhold

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

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

Show quoteHide quote

Lev Elbert <elbert***@hotmail.com> wrote:
Is a regular expression + TextReader.ReadLine really so hard?

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> Lev Elbert <elbert***@hotmail.com> wrote:
J>
J> Is a regular expression + TextReader.ReadLine really so hard?
J>

How would you use regular expression?

Marathoner

Show quoteHide quote

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

Show quote Hide quote 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.

jehugalea***@gmail.com <jehugalea***@gmail.com> wrote:
It's still an abuse of operator overloading, IMO.

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.

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.

Indeed.

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.

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

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);


Show quoteHide quote

Using CSharpCodeProvider to create MANY assemblies
Assigning a reference to a variable
Dispose(bool), Idisposable, form closing etc.
problems using the tablelayoutpanel in VS2005
How do you make a variable persist in memory?