Question about getline with fstream

[pbuk]

BUT it's strange, if I replace if(!people.eof()), it failed the first time without printing anything!

I don't find that strange: the ! is doing exactly what I would expect. Do you think it should be there?

I thought we should test for eof(), not fail. How do you know that?

Well testing for eof would work in this case, but there are other reasons a read can fail so you should always check that a read has worked before you assume that it has and press on regardless.

It is also good practice not to return out of a loop like this, instead of return use break and after the loop you can then test to see whether the last record in the file was read successfully or not.

 

[Jarvis323]

There is no error, it's the expected behavior. eof is set not when you've reached the end, but when you've tried to read passed the end. They should have named it peof (passed end of file).

 

[yungman]

I think I understand why now. With testing eof(), it has to reach '\0' before it say it's eof.

I was playing with testing the length of file and I got one more than expected, I kind of suspect it's the eof.

#include <iostream>
#include <fstream>
#include <string>
using namespace std;

int main()
{
    char alp[] = "abcdefghijklmnopqrstuvwxyz";//contain 26 characters
    fstream alphabet;
    alphabet.open("alp.dat", ios::out | ios::binary);
    if (!alphabet)
    alphabet.write(alp, sizeof(alp));
    alphabet.close();

    alphabet.open("alp.dat", ios::in | ios::binary);
    alphabet.seekg(0, ios::end);
    cout << " Length of string = " << alphabet.tellg() << "\n\n";//read 27bytes

    return 0;
}

It reported back the length of the string is 27bytes instead of expected 26.

Is this the same idea as my problem reading michael twice because after read the michael the first time, it's not the end of file yet, I have to read one more time to get it to eof()?

Thanks

 

[Jarvis323]

I think I understand why now. With testing eof(), it has to reach '\0' before it say it's eof.

I was playing with testing the length of file and I got one more than expected, I kind of suspect it's the eof.

#include <iostream>
#include <fstream>
#include <string>
using namespace std;

int main()
{
    char alp[] = "abcdefghijklmnopqrstuvwxyz";//contain 26 characters
    fstream alphabet;
    alphabet.open("alp.dat", ios::out | ios::binary);
    if (!alphabet)
    alphabet.write(alp, sizeof(alp));
    alphabet.close();

    alphabet.open("alp.dat", ios::in | ios::binary);
    alphabet.seekg(0, ios::end);
    cout << " Length of string = " << alphabet.tellg() << "\n\n";//read 27bytes

    return 0;
}

It reported back the length of the string is 27bytes instead of expected 26.

Is this the same idea as my problem reading michael twice because after read the michael the first time, it's not the end of file yet, I have to read one more time to get it to eof()?

Thanks

No, after reading Michael it is the end of the file, but eof doesn't mean end of the file, it means beyond the end of the file (or attempted to go beyond the end of the file).

Like Mark said, it is an indicator why the read failed. If it fails because you tried reading too much/far, then eof is set so that you know the reason. It means that the read failed because you've tried to read beyond the end of the file.

And there is no terminating character for a struct.

 

[Mark44]

I think I understand why now. With testing eof(), it has to reach '\0' before it say it's eof.

No, the null character has nothing to with the end of a file. The null character, '\0', is used to mark the byte just beyond the end of a C-string. Furthermore, there is no special character that marks the end of the file - the OS knows how many bytes are in a file, so it "knows" when your program is attempting to read beyond the last byte in a file -- that's when eof() returns true.

 

[FactChecker]

I don't know why the people who wrote the C++ standard that introduced std::string didn't simply add an overloaded version of the fstream getline() member function that accepts a std::string.

Perhaps they were trying to block people from using the C string functions that allow all the viruses that go beyond the read buffer length.

 

[yungman]

Thanks guys, I did not know a simple eof() can be this confusing. I have to go back and read exactly what eof() means after dinner and all.

Thanks

 

[FactChecker]

Thanks guys, I did not know a simple eof() can be this confusing. I have to go back and read exactly what eof() means after dinner and all.

Thanks

It's really very simple. It is triggered by the error of trying to read data beyond the end of the valid data in the file. The valid data in the file includes any '\0' there indicating the end of a string.

 

[pbuk]

Is this the same idea as my problem reading michael twice because after read the michael the first time, it's not the end of file yet, I have to read one more time to get it to eof()?

No, it doesn't read "Michael" a second time, it prints it a second time because you don't test whether people.read() has succeeded before you go ahead and print the last value that you read into person. The reason people.read() fails on the 5th pass through the loop is because it attempts to read beyond the end of the file (and therefore the subsequent call to people.eof() returns true).

You will not understand what is happening until you realize that "Michael" is only being read once.

 

[yungman]

OK, I just went back and read the book, I even have an exercise program to test eof() RIGHT after reading the last piece of data.

#include <iostream>
#include <fstream>
using namespace std;
int main()
{//Create a file and write int 10 in it, only one integer data.
    int num = 10;
    fstream testFile;
    testFile.open("demofile.txt", ios::out);
    cout << " Writing 10 " << num << " to file.\n";
    testFile << num;
    cout << " testFile.eof() = " << testFile.eof() << "\n\n";
    testFile.close();// close file
//Read from file that has only one integer data.
    testFile.open("demofile.txt", ios::in);//open for read
    cout << " Read file. \n";
    testFile >> num; //read file to num
    cout << " The value   " << num << "   was read.\n\n";
    cout << " testFile.eof() = " << testFile.eof() << "\n\n";
    return 0;
}

Like before, I got rid of if(!testFile.fail()). It's NOT FAILING so I can make it as short as possible to post here.
You run this program, you don't have to do anything. The program
1) Create the file and write ONLY one integer 10 into the file.
2) Close the file.
3)Open that file.
4)Read the only value of integer 10.
5) Read the eof() bit Right after reading. The bit show testFile.eof() = 1;

This is just like in my program

    do
    {
        people.read(reinterpret_cast<char*>(&person), sizeof(person));
    } while (!people.eof());

I went through the book, it DOES NOT explain eof(). But it makes sense that you read the byte where the internal pointer is pointing. If it is the last byte, it read out the last byte. Then the pointer ADVANCE to the next byte which is '\0'. When the pointer points to '\0', the eof bit will change to 1 right away.

 

[FactChecker]

If you look at the file demofile.txt is the number in it?

 

[yungman]

If you look at the file demofile.txt is the number in it?

Yes. one single number 10.

 

[FactChecker]

I stand corrected. The eof()=1 is not an error from trying to read too much from the file. It is just an indicator that there is no more data to be read from the file. If you try to read beyond the end-of-file, both the eof and fail flags will be set, but if you only read to the end-of-file only the eof flag is set. (See http://www.cplusplus.com/reference/ios/ios/eof/ )

 

[yungman]

I stand corrected. The eof()=1 is not an error from trying to read too much from the file. It is just an indicator that there is no more data to be read from the file. If you try to read beyond the end-of-file, both the eof and fail flags will be set, but if you only read to the end-of-file only the eof flag is set. (See http://www.cplusplus.com/reference/ios/ios/eof/ )

Thanks, I read the program in the link, seems it's like what the eof checking program in post 40...That after reading the last byte, the pointer advances and pointing to '\0', thereby the eof bit is set right away as shown in post 40. this is the copy of program from cplusplus you linked:

// ios::eof example
#include <iostream>     // std::cout
#include <fstream>      // std::ifstream

int main () {

  std::ifstream is("example.txt");   // open file

  char c;
  while (is.get(c))                  // loop getting single characters
    std::cout << c;

  if (is.eof())                      // check for EOF
    std::cout << "[EoF reached]\n";
  else
    std::cout << "[error reading]\n";

  is.close();                        // close file

  return 0;
}

Line 14 implies you should see eof() after the last read right away.
That's still doesn't explain why I read michael twice before the eof bit is set. You can see it as I cout << !people.eof() and show the bit was NOT set after reading michael the first time, only set after reading the second time.

I went through the book, it does not explain the mechanism, so I am just guessing. In the cplusplus link you gave, it said:

This flag is set by all standard input operations when the End-of-File is reached in the sequence associated with the stream.

Note that the value returned by this function depends on the last operation performed on the stream (and not on the next).
Sounds like the eof is set right after reading the last byte of data.

 

[Jarvis323]

#include <iostream>
#include <fstream>

int main () {

  std::ifstream is("example.txt");

  char c;
  while (is.get(c))     //   When does this loop condition become false?
    std::cout << c;

  if (is.eof())              // eof is reached after the loop condition became false
    std::cout << "[EoF reached]\n";
  else
    std::cout << "[error reading]\n";

  is.close();                  
  return 0;
}

I added comments which should help you out on this.

Notes

This function only reports the stream state as set by the most recent I/O operation; it does not examine the associated data source. For example, if the most recent I/O was a get() which returned the last byte of a file, eof() returns false. The next get() fails to read anything and sets the eofbit. Only then does eof() return true.

In typical usage, input stream processing stops on any error. eof() and fail() can then be used to distinguish between different error conditions.

https://en.cppreference.com/w/cpp/io/basic_ios/eof

eof is apparently kind of complicated (depends on the IO operation) and not explained well.

At least for get and read (and other "unformated" io operations), it is set after trying to read past the end of the file, but for "formatted" IO operations (which includes <<) it's more complicated.

 

[Mark44]

Thanks, I read the program in the link, seems it's like what the eof checking program in post 40...That after reading the last byte, the pointer advances and pointing to '\0', thereby the eof bit is set right away as shown in post 40.

The program you're referring to is not working with C-strings. As I already said, the null character, '\0', is used to indicate the end of a string. The null character is NOT used to mark the end of a file.
Post #39

You will not understand what is happening until you realize that "Michael" is only being read once.

Post #44

That's still doesn't explain why I read michael twice before the eof bit is set.

That name was NOT read twice!

Please read replies to your questions more carefully!

This is just like in my program

    do
    {
        people.read(reinterpret_cast<char*>(&person), sizeof(person));
    } while (!people.eof());

No, the two programs are not alike. In the first (post #28, I think), you opened the file in binary mode, and used read() to extract the data. The more recent program, in post #40, works with a text file, and uses the stream extraction operator, >>, to get the data.

If I modify your latest program to work like the earlier program, I get different behavior regarding eof().

#include <iostream>
#include <fstream>
using namespace std;
int main()
{   //Create a file and write an int value into it.
    int num = 10;
    int val;
    fstream testFile;

    testFile.open("demofile.txt", ios::out|ios::binary);  // Open for writing in binary mode
    cout << " Writing " << num << " to file.\n";
    //testFile << str;            // From earlier program
    testFile.write((char*)&num, sizeof(num));
    cout << " testFile.eof() = " << testFile.eof() << "\n\n";
    testFile.close();// close file

    testFile.open("demofile.txt", ios::in|ios::binary);    //Open for reading in binary mode
    cout << " Read file. \n";
    //testFile >> str2; // From earlier program
    testFile.read((char*)&val, sizeof(val));
    cout << " The value   " << val << "   was read.\n\n";
    cout << " testFile.eof() = " << testFile.eof() << "\n\n";
    testFile.close();     
}

Output:

 Writing 10 to file.
testFile.eof() = 0

Read file.
The value   10   was read.

testFile.eof() = 0

Note that after reading the value in the file, testFile.eof() is false. Obviously reading a file using >> is different from doing so with read(). With read(), you indicate how many bytes you want to read. If it doesn't run out of bytes to read, then eof() is false.

 

[yungman]

#include <iostream>
#include <fstream>

int main () {

  std::ifstream is("example.txt");

  char c;
  while (is.get(c))     //   When does this loop condition become false?
    std::cout << c;

  if (is.eof())              // eof is reached after the loop condition became false
    std::cout << "[EoF reached]\n";
  else
    std::cout << "[error reading]\n";

  is.close();                 
  return 0;
}

I added comments which should help you out on this.https://en.cppreference.com/w/cpp/io/basic_ios/eof

eof is apparently kind of complicated (depends on the IO operation) and not explained well.

At least for get and read (and other "unformated" io operations), it is set after trying to read past the end of the file, but for "formatted" IO operations (which includes <<) it's more complicated.

Thanks, this is very helpful. The book just doesn't say anything about this. You would think for files, eof() means the same thing. I've been doing more experiments:

#include <iostream>
#include <fstream>
#include <string>
using namespace std;

int main()
{
    char name[100];
    fstream people;
    people.open("people.dat", ios::out | ios::binary);
    people << "alan ";
    people << "Paul ";
    people << "john ";
    people << "michael";
    people.close();

    people.open("people.dat", ios::in | ios::binary);
    do
    {
        people >> name;
        cout << " Name: " << name << "   !people.eof() = " << !people.eof() << "\n\n";
    } while (!people.eof());
    people.close();
}

I eliminated the writing to struct all together and just write the 4 names into the file, then I just read back.

First, I have to put a space after each name to separate them or else they will be alanPauljohnmichael upon the first read and !people.eof()=0;

I have to put a space after each name, but then you can see !people.eof()=1 after reading michael. The last read is blank, I believe it read the white space I put in after michael. I eliminate the space after michael, it will do everything correctly, only print michael once and exit the program.

I believe in the original program, michael is being read twice. It just using struct, there must be something that cause the eof() to stay as 0 after reading michael the first time.

I change to run the program in TEXT file instead of binary file. RESULT IS EXACTLY THE SAME. There is no difference between text and binary file.

 

[yungman]

The program you're referring to is not working with C-strings. As I already said, the null character, '\0', is used to indicate the end of a string. The null character is NOT used to mark the end of a file.
Post #39
Post #44
That name was NOT read twice!

Please read replies to your questions more carefully!

No, the two programs are not alike. In the first (post #28, I think), you opened the file in binary mode, and used read() to extract the data. The more recent program, in post #40, works with a text file, and uses the stream extraction operator, >>, to get the data.

If I modify your latest program to work like the earlier program, I get different behavior regarding eof().

#include <iostream>
#include <fstream>
using namespace std;
int main()
{   //Create a file and write an int value into it.
    int num = 10;
    int val;
    fstream testFile;

    testFile.open("demofile.txt", ios::out|ios::binary);  // Open for writing in binary mode
    cout << " Writing " << num << " to file.\n";
    //testFile << str;            // From earlier program
    testFile.write((char*)&num, sizeof(num));
    cout << " testFile.eof() = " << testFile.eof() << "\n\n";
    testFile.close();// close file

    testFile.open("demofile.txt", ios::in|ios::binary);    //Open for reading in binary mode
    cout << " Read file. \n";
    //testFile >> str2; // From earlier program
    testFile.read((char*)&val, sizeof(val));
    cout << " The value   " << val << "   was read.\n\n";
    cout << " testFile.eof() = " << testFile.eof() << "\n\n";
    testFile.close();    
}

Output:

 Writing 10 to file.
testFile.eof() = 0

Read file.
The value   10   was read.

testFile.eof() = 0

Note that after reading the value in the file, testFile.eof() is false. Obviously reading a file using >> is different from doing so with read(). With read(), you indicate how many bytes you want to read. If it doesn't run out of bytes to read, then eof() is false.

I KNOW what you said before, I am not convinced, see the post I reply to Jarvis. I don't think the book will ignore this if that is true. I think some else is going on.

 

[yungman]

The program you're referring to is not working with C-strings. As I already said, the null character, '\0', is used to indicate the end of a string. The null character is NOT used to mark the end of a file.
Post #39
Post #44
That name was NOT read twice!

Please read replies to your questions more carefully!

No, the two programs are not alike. In the first (post #28, I think), you opened the file in binary mode, and used read() to extract the data. The more recent program, in post #40, works with a text file, and uses the stream extraction operator, >>, to get the data.

If I modify your latest program to work like the earlier program, I get different behavior regarding eof().

#include <iostream>
#include <fstream>
using namespace std;
int main()
{   //Create a file and write an int value into it.
    int num = 10;
    int val;
    fstream testFile;

    testFile.open("demofile.txt", ios::out|ios::binary);  // Open for writing in binary mode
    cout << " Writing " << num << " to file.\n";
    //testFile << str;            // From earlier program
    testFile.write((char*)&num, sizeof(num));
    cout << " testFile.eof() = " << testFile.eof() << "\n\n";
    testFile.close();// close file

    testFile.open("demofile.txt", ios::in|ios::binary);    //Open for reading in binary mode
    cout << " Read file. \n";
    //testFile >> str2; // From earlier program
    testFile.read((char*)&val, sizeof(val));
    cout << " The value   " << val << "   was read.\n\n";
    cout << " testFile.eof() = " << testFile.eof() << "\n\n";
    testFile.close();   
}

Output:

 Writing 10 to file.
testFile.eof() = 0

Read file.
The value   10   was read.

testFile.eof() = 0

Note that after reading the value in the file, testFile.eof() is false. Obviously reading a file using >> is different from doing so with read(). With read(), you indicate how many bytes you want to read. If it doesn't run out of bytes to read, then eof() is false.

I think it's time for me to move on. Someone gave me a link that really solve the problem, I cannot find that post anymore. Basically it do the read first in line 2 before enter the do-while loop and it works.

    people.open("people.dat", ios::in | ios::binary);
    people.read(reinterpret_cast<char*>(&person), sizeof(person));
    do
    {
        cout << " Name: " << person.name << "\n";
        cout << " Age: " << person.age << "\n";
        cout << " Enter address line 1: " << person.address1 << "\n\n";
        cout << " Enter address line 2: " << person.address2 << "\n\n";
        cout << " Enter phone number: "<< person.phone << "\n\n";
        people.read(reinterpret_cast<char*>(&person), sizeof(person));
        index++;
        cout << " index = " << index << "    !people.eof() = " << !people.eof() << "\n\n";
    } while (!people.eof());

Something is inconsistent in this eof(), I just don't have the knowledge to dig deeper, so it's best to get on with this, put in my cheat sheet and hurry up to get onto Chapter 13 Classes.

thanks

 

[sysprog]

@yungman $-$ have you fully considered the fact that C++ is a strictly-typed language? That fact has important implications and consequences. Please read up on them.

 

[yungman]

@yungman $-$ have you fully considered the fact that C++ is a strictly-typed language? That fact has important implications and consequences. Please read up on them.

What do you mean typed language?

 

[sysprog]

What do you mean typed language?

I mean that when you pass values, the 'type' of the value, for example 'character', is enforced $-$ if you try to do an arithmetic operation on character data your program will fail $-$ e.g. you can't multiply L by M

 

[Mark44]

I believe in the original program, michael is being read twice. It just using struct, there must be something that cause the eof() to stay as 0 after reading michael the first time.

The original program was using read() to do the extraction from the file. The behavior with eof() has nothing to do with the string being in a struct.

And no, the string "michael" is NOT read twice.

I change to run the program in TEXT file instead of binary file. RESULT IS EXACTLY THE SAME. There is no difference between text and binary file.

I KNOW what you said before, I am not convinced, see the post I reply to Jarvis. I don't think the book will ignore this if that is true. I think some else is going on.

What's going on is that read() extracts a specific number of bytes, and the extraction operator >> extracts characters of a string until it reaches the null character.

Something is inconsistent in this eof(), I just don't have the knowledge to dig deeper, so it's best to get on with this, put in my cheat sheet and hurry up to get onto Chapter 13 Classes.

What's the rush? Skipping over things you don't understand will almost certainly come back to bite you in the butt. And "hurrying up" has caused many problems for you in the past couple of months.

I'll grant you that checking for eof() is tricky. It's more complicated due to several factors -- whether the file is being read in text mode or binary mode, and whether you're doing the reading with read() or with the extraction operator >>. If a read() encounters the end of the file before the specified number of bytes, eof() will return true. Otherwise it will be false. If you're extracting a string from a file, >> won't extract the null character at the end of the string.

In the program below, I create a file in binary mode, and write the C-string "cats" and a single byte, 'A'.
The contents of the file are the ASCII codes for 'c' 'a' 't' 's' '\0' 'A'.
I get different behavior if I then open the file for input in binary mode, or if I open it for input in text mode.
BTW, if you are going to read a file in binary mode, you should use read(), not >>.

When I open the file for reading in binary mode, I read() 5 bytes, the four alpha characters and the null.

When I open the file for reading in text mode, the insertion operator gets the four alpha characters, but leaves the null character in the file. I've looked at the VS docs and cplusplus.com, but I don't know what the actual mechanism is -- if the null is not read, or if it's read but inserted back in the file.

Here's an example.

#include <iostream>
#include <fstream>
using namespace std;
int main()
{      
    char testStr[] = "cats";
    char num = 65;
    char val;
    char testStr2[5];
    char testStr3[5];
    char ch;
    fstream testFile;

    testFile.open("demofile.txt", ios::out|ios::binary);
    cout << " Writing the string \"cats\"" <<" and a byte to file.\n";
    testFile.write(testStr, sizeof(testStr));
    testFile.write((char*)&num, sizeof(num));
    testFile.close(); 
    

    testFile.open("demofile.txt", ios::in|ios::binary);
    cout << " Read file in binary mode using read(). \n";
    testFile.read(testStr2, sizeof(testStr2));
    testFile.read((char*)&val, sizeof(val));
    cout << " String:  " << testStr2 << " and value: " << val << "\n";
    cout << " testFile.eof() = " << testFile.eof() << "\n";
    ch = testFile.get();
    cout << " After get(), testFile.eof() = " << testFile.eof() << "\n\n";
    testFile.close();
    testFile.clear(0);   // Clear all flags - eofbit, failbit, badbit

    ch = 'Z';
    val = 0x7F;
    testFile.open("demoFile.txt", ios::in);
    cout << " Read file in text mode using extraction operator. \n";
    testFile >> testStr3;
    testFile >> ch;
    cout << " After extracting ch, testFile.eof() = " << testFile.eof() << "\n";
    testFile >> val;
    cout << " After extracting val, testFile.eof() = " << testFile.eof() << "\n";
    cout << " String: " << testStr3 << " and value: " << val << "\n";
    ch = testFile.get();
    cout << " After get(), testFile.eof() = " << testFile.eof() << "\n";
    testFile.close();
}

The output from the above. I've added comments to explain why something happened, but otherwise the output is as I saw it.

 Writing "cats" and a byte to file.
 Read file in binary mode using read().
 String:  cats, value: A                // Both values are read
 testFile.eof() = 0                         // After read() of the string, and read() of the byte, we're not at end of file
 After get(), testFile.eof() = 1    // One more read, using get() and eof() is true

 Read file in text mode using extraction operator.
 After extracting ch, testFile.eof() = 0           // String extracted, and null (ch - with value '\0') extracted - no eof. 
 After extracting val, testFile.eof() = 0          // val extracted - no eof.
 String: cats, value: A                                     // Both values are read
 After get(), testFile.eof() = 1             // Final read, using get() and eof() is true.

 

[sysprog]

@Mark44 back in the day ('70s) IBM advised us to if we were reading whole card pictures (80-characters) and writing whole (133 column green-bar paper) line-printer print lines use GETLINE and PUTLINE, instead of TGET and TPUT, presumably for the sake of efficiency, even though TGET and TPUT, despite having been written for the Teletype (TTY 110) terminal, could read and write from and to anywhere.

 

[yungman]

....
What's going on is that read() extracts a specific number of bytes, and the extraction operator >> extracts characters of a string until it reaches the null character.
What's the rush? Skipping over things you don't understand will almost certainly come back to bite you in the butt. And "hurrying up" has caused many problems for you in the past couple of months.

I'll grant you that checking for eof() is tricky. It's more complicated due to several factors -- whether the file is being read in text mode or binary mode, and whether you're doing the reading with read() or with the extraction operator >>. If a read() encounters the end of the file before the specified number of bytes, eof() will return true. Otherwise it will be false. If you're extracting a string from a file, >> won't extract the null character at the end of the string.

..........

Thanks a million!
I think this is the first time it makes sense to me.

Let me repeat back to you to confirm. read() reads VERY SPECIFIC number of bytes according the datatype that it's supposed to read. If read() gets the correct number of bytes, it's happy, eof() remain 0. This means when it reads michael, it GOT the correct number of bytes and left eof()=0. It's ONLY it the next read that it is not getting the bytes as it's the end already, then eof() is changed to 1.

I have a question, name has different length, how does read() know when it has enough bytes. Does it look for a character to know it's complete?

Now this make a world of sense. Please let me know whether I am right or not.

Thanks

As for why am I rushing, I always set goals, I am very goal oriented, I set my goal to finish this chapter in less than 2 weeks, because of reinterpret_cast, I spent two days, and I spent two days on this. That's why I am kind of want to move on. A lot of times I notice the book throw out something without explaining, it must be the author think it's better to use it and explain more when the time is right. It's like if the book tries to explain what is datatype, object, instance before letting student just define int x = 5 in chapter 1, we'd never get through chapter one. In fact, that's how I felt when I asked a question here, you guys explained and it's like Russian to me. Took me till lately that I understand datatype and all on int x = 5!

 

[Mark44]

Nobody responded to your code in post #47 and your comments.

You would think for files, eof() means the same thing. I've been doing more experiments:

#include <iostream>
#include <fstream>
#include <string>
using namespace std;

int main()
{
    char name[100];
    fstream people;
    people.open("people.dat", ios::out | ios::binary);
    people << "alan ";
    people << "Paul ";
    people << "john ";
    people << "michael";
    people.close();

    people.open("people.dat", ios::in | ios::binary);
    do
    {
        people >> name;
        cout << " Name: " << name << "   !people.eof() = " << !people.eof() << "\n";
    } while (!people.eof());
    people.close();
}

First, I have to put a space after each name to separate them or else they will be alanPauljohnmichael upon the first read and !people.eof()=0;

No, you put a space after the first three names, but not the fourth.
In the loop that reads from the file, the first three names are extracted with no problems, but the fourth extraction fails, because the >> operator extracts m i c h a e l, and keeps extracting, thus causing eof() to be true.
A very simple fix is to add a trailing space on the string "michael ". Then all four names are extracted from the file, and the next extraction fails with eof() becoming true.

 

[sysprog]

With caution that the persons there maybe are not always as friendly as PF members have proven themselves to be, maybe please read: https://stackoverflow.com/questions...ction-know-when-there-is-nothing-left-to-read

 

[sysprog]

@Mark44 I plead overlap - I would have let your post #56 suffice, had I read it before posting my #57 - Regards -

 

[Mark44]

Let me repeat back to you to confirm. read() reads VERY SPECIFIC number of bytes according the datatype that it's supposed to read. If read() gets the correct number of bytes, it's happy, eof() remain 0. This means when it reads michael, it GOT the correct number of bytes and left eof()=0. It's ONLY it the next read that it is not getting the bytes as it's the end already, then eof() is changed to 1.

No, it's not according to the datatype that will be read -- it's according to the number of bytes that are supposed to be read. If the call to read() indicates that N bytes should be read, and read processes N bytes, then eof() is false. If read() is able to read only M bytes, where M < N, the eof() returns true.
For example,

testFile.read(testStr2, sizeof(testStr2));

Here testStr2 is declared as an array of type char, with 5 bytes. Notice that I don't need a cast of any kind, because testStr2 is already a char pointer. The 2nd argument says to process 5 bytes. As long as there are 5 bytes left in the file, eof() will be false.

I have a question, name has different length, how does read() know when it has enough bytes. Does it look for a character to know it's complete?

The 2nd argument to read() is the number of bytes to read.

As for why am I rushing, I always set goals, I am very goal oriented, I set my goal to finish this chapter in less than 2 weeks, because of reinterpret_cast, I spent two days, and I spent two days on this.

Goals are based on plans, and plans are subject to some events that are difficult to forecast correctly. When that happens, the wise thing to do is to reassess the plans and possibly adjust the timeline for the goals.

 

[phinds]

As for why am I rushing, I always set goals, I am very goal oriented, I set my goal ...

And does it ever happen that it turns out that your goals are unrealistic and you have to do an inadequate and rushed job to meet them instead of just taking longer and doing a good job? Maybe you set the wrong goal. You set a TIME goal. Why not set a LEARNING goal instead?