The problem is that, once you've processed the stream, its gone and it might
not be easy to reopen the file. This means the solution won't scale up.
The string solution is also more likely to be re-usable, and it is easier to
construct test cases.
Where is the need to read a stream more than once when you've
processed anything?
If you needs the stram tiled in words, then do it, if you needs the
stream tiled in numbers, words, lines, char, you can do it without
touching a chare again after you've processed it.
Does you really think it is better to copy a number of characters from
here to there to there to there to process it only to copy it from
there to there again?
Does you like a very complex sample how to read a stram once, scan it
multiple times, check for highly different things - but having the
straem reading once?
try a look into bison or yacc. You can use them for any parsing you
may ever need - but as you have seldom really complex syntax rules it
is more often enough to write your parser youself. Breaking a line in
its kown components is easy, if you can't trust the soure (like that
what can come from a keyboard) you may have the need for more
extensive testing. But anyway you can work straight forward. Means
when you gets confused you can simply read away anything until you
gets a known sync point, such as a seaparator char (';' or '\n' or
something elsy you knows it is) and restart from phase 1 with it.
If your parsing needs to read ahead more than one char then it is not
too complex to write a wrapper around getc() and ungetc() to write
more than one char back into the stream. You needs the wrapper because
ungetc() can only write back one char.
But at least you saves the overhead of dynamic allocated and extended
input buffers. Even as often you may need dynamic sized output fields.
You can easy tokenise the stream without using strtok. You can easy
convert any kind of number to binary on the fly, you can easy separate
strings from another on the fly whereas you needs nothing than some
kinds of separators (whitre spaces, commas, single or double quotes,
colons, semicolons.....). Some of them may be only seperators in some
cases (e.g. decimal points during read of a float, '-'/'+' sing in
some positions......
You should know that C works with streams. A stream is nothing more
than a serial sequence of characters. Even as some functions in the
standard library concencates a number of chars to a buffer, the stream
itself lefts always as a pure sequence of chars.
So, always when you have to read an untrusted stream, it is always the
best to read it char by char to save any overhead.
When you doesn't hack but you're programming you'll find this idea
wounderful.
--
Tschau/Bye
Herbert Rosenau
http://www.pc-rosenau.de eComStation Reseller in Germany
eCS 1.1 german is in beta testing
