Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Actually, boost is a collection of libraries for C++. Some of which comes in handy very much.
What I showed in my example is called integer traits. Basically, it defines various properties of certain types.
It provides constant numbers for maximum and minimum values the types can hold along with something else and gets the rest of the information by deriving from STL's integer traits.
When i write records on a text file i use '\n' at the end of each record so that all records can be on separate lines... Now the challenge is there's always going to be an empty line a at the last record... Been thinking of a way to avoid cause when reading from same file, this record reads as junk... any ideas??
If you read using >> x, then it will "fail" if it can't read valid data after the newline, so all you need to do is to check the result of the read operation. Fortunately, that's easy, because the bool operator of the stream class returns false if the stream encountered an error (such as end of file).
So just doNote that it doesn't matter that we tried to read the ENTIRE car record - it will fail when it reaches end of file, and assuming your data file is correctly built, that would happen just after your last end-of-line marker.Code:if (!fin >> car) // Reached end of file, stop reading else // process car (e.g. insert into vector).
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
as this is my record
i'm guessing then it would be more appropriate to check the first fieldCode:in >> make >> model; in >> regNo; in >> ymodel; in >> engCap; in >> ts;
i.e
Code:if (!in >> make ) return -1; // Can i return -1 to istream? else { in >> model; in >> regNo; in >> ymodel; in >> engCap; in >> ts; }
Well, in that case, you should check ALL of them - what if you have make, model, regno <end of file> because of some system error (full disk, power failure/system crash)?
Edit: Just checking if(!in) after you have read all the fields [any or all of which may have failed] will tell you if it failed, or on the else-side, succeeded.
Edit2: If it's a operator>> then you will return in itself, and that will be sufficient to check at the calling point. No need to return a bool/integer value from this function in that case.
--
Mats
Last edited by matsp; 07-22-2008 at 02:43 AM.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
You could just do:
and use it like:Code:istream& Car::Read(istream& indata, Car& car, bool isKeyword) { return indata >> car; }
Then, in case of failed input you could use more specialized functions to find out what went wrong (if that is important to you).Code:if (!car.Read(fleetin, car, false) { //input failed }
Also, in the above usage, what is the point to pass car as an argument if this function is already called on the car instance and car is already passed as the this pointer. Simpler:
Code:car.Read(fleetin, false);
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
You dereference it like other pointers:
Code:indata >> *this;
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
You may want *this, as this is a pointer to car, which won't be available as a "read into this type" overloaded operator>> .
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
For this program, which would you recommend and why (advantages)?
Seeing as you need to have a car to read in the value anyways, you may just as well use the "this" pointer that is already there. Is Car::Read a static function? If not, it is being passed "this" as well as car, so if you do car.Read(... car ...) then you are effectively passing car along twice - once as this, and second as a parameter. Seems unnecessary, and there's no purpose (or advantage) to having a Car reference parameter to a function that requires to have a Car object to be called. Since "simpler is better", this gives the advantage to the model that anon is suggesting.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.