Re: Filestream input kickin my arse
On 26 mar, 20:19, "drmario" <drma...@cox.net> wrote:
I don't really have the restrictions that I implied I did.
The professor said we can do it however we want, but gave no
guidelines as to how much error/format checking is involved.
In which case, I would guess that not handling errors graciously
would result in a definitely lower grade.
So of course most students will use proven libraries (which is
smart of course, cuz it's faster and more efficient),
You'd be surprised. Most students aren't that intelligent, and
will reinvent the wheel, rather than looking things up to do
them correctly.
and assume that everything will be formatted 100% correctly,
in order to do the least ammount of work.
Assuming 100% correct formatting is an error, IMHO. Unless
you've been explicitly told that it's OK (since the goal of the
project is to teach something else).
Not me. I don't like using libraries when I'm first learning,
The line between standard libraries and the compiler is a fine
one. In this case, as I said, if I didn't have the standard
library, the first thing I'd do is write some sort of string
class and a getline function. (In fact, I learned C++ long
before there was a standard library, a my string class was
probably the first thing I wrote. Like most other people at the
time.)
In the case of I/O, of course, you almost have to use the
standard library if you want your code to be portable. The
system level calls are not the same for Unix and for Windows.
and I hate wizards in that capacity too. I like to know
what's going on behind the scenes before I start using
libraries that encapsulate that functionality. If it were up
to me I'd write every program in assembly first, to understand
what was going on, then rewrite in a higher language.
That's the way I learned. But I'm not sure it's the most
effective way. I actually started with transistors, learned how
to implement gates with them, then how do put the gates together
to create registers and an adder. Before I wrote my first line
or assembler. So where to you stop?
The important reason for using a high level language is the
abstraction. The fact that you don't have to understand all
this to use it. And that even if you do understand it, you more
or less forget it when using the language.
So the restrictions you saw were self-imposed to force an
understanding of I/O. It works too cuz a few days ago I knew
only basics about C++ I/O. Today I'm digging through the
debugger values for my ifstream variable looking for the value
that represents ios_base::iostate. I wanna find out exactly
when the input failure is occuring.
Have fun:-). One really major weakness of I/O, both in C and in
C++, is that their error handling tends to mask the real causes.
Personally, I think you'd be better off doing thing the opposite
way. Write something that works first, then try to undestand
why it works: what services the library is providing, for
example. The try replacing some parts of the library with your
own code.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34