Mysterious Error: Can You See Why?

[yungman]

I encountered a strange error. I have 2 EXACTLY same code in this program, I just use /* */ to disable one or the other. The bottom one works, the top one giving me error. I literally copied the content inside main() from the bottom to the top, still, the top one fails and bottom works.

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

main()
{
    fstream    dataFile;
    dataFile.open("C:\\Users\\alanr\\Desktop\\C++ exercise\
\\Gaddis\\inout files\\demofile.txt", ios::out | ios::app);
    dataFile << " Lucky " << " Chicky\n\n" << " Slave " << " Rooster\n\n";
    dataFile.close();
    return 0;
}
/*#include <iostream>
#include <fstream>
#include <iomanip>

using namespace std;

int main()
{
    fstream    dataFile;
    dataFile.open("C:\\Users\\alanr\\Desktop\\C++ exercise\
\\Gaddis\\inout files\\demofile.txt", ios::out|ios::app);
    dataFile << " Lucky " << " Chicky\n\n" << " Slave " << " Rooster\n\n";
    dataFile.close();

    return 0;
}*/

If I missed anything, I must be really blind. Like I said, I copied the content inside main() from bottom to the top, still have problem.

The error is :

And when I choose run anyway, the error is:

I did closed the VS and start over, also, I clean Build solution every time also. Also, I printed the code out and compared word by word. Can you see why?

thanks

 

[berkeman]

They are not exactly the same...

 

[yungman]

They are not exactly the same...

The content is the same. I copied the lines inside main() from the bottom to the top except return0;

You can see line 8 to line 12 is the copy from the bottom line 23 to 27.

 

[berkeman]

The content is the same. I copied the lines inside main() from the bottom to the top except return0;

You can see line 8 to line 12 is the copy from the bottom line 23 to 27.

Spoiler

main()
int main()

I don't know if that's the source of the error, but it appears that it was not a true copy/paste...

 

[yungman]

Spoiler

main()
int main()

I don't know if that's the source of the error, but it appears that it was not a true copy/paste...

My god, I only look at the inside content! Thank you. I wasted an afternoon, comparing word by word inside main!

Funny, I did that quite a few times, the compiler always flag me if I forgot "int" before main. It didn't this time. I went back and look at the program, it does not have red wiggle line under that. I know because it happened many times before and it will show the error so I know to put it in.

Thanks

 

[Mark44]

I wasted an afternoon, comparing word by word inside main!

Look at the error the compiler gave you -- it says the problem is on line 7. You can also double click on the error code, C4430, which will take you to a doc page for that error. No guarantee that it will be all that helpful. Several of the examples you've posted had compile-time errors. You could have saved yourself a lot of time by looking at the information that is shown in the error window.

main()
int main()

I don't know if that's the source of the error, but it appears that it was not a true copy/paste...

It is indeed the source of the error.
Edited to add "not" -
Also, if the compiler generated an error, as opposed to a warning, I'm pretty sure that an .exe file was not generated. So I'm not clear why you would even have been able to run the program.

 

[sysprog]

Look at the error the compiler gave you -- it says the problem is on line 7. You can also double click on the error code, C4430, which will take you to a doc page for that error. No guarantee that it will be all that helpful. Several of the examples you've posted had compile-time errors. You could have saved yourself a lot of time by looking at the information that is shown in the error window.

It is indeed the source of the error.

Also, if the compiler generated an error, as opposed to a warning, I'm pretty sure that an .exe file was generated. So I'm not clear why you would even have been able to run the program.

Didi you mean to say that the .exe file would not be generated? (unless it's a debug version) why would an object file be created and then linked into "an .exe file" if the compiler reported an error? I think that you're better at this stuff than I am, @Mark44; would you please clarify this?

 

[256bits]

Also, if the compiler generated an error, as opposed to a warning, I'm pretty sure that an .exe file was generated. So I'm not clear why you would even have been able to run the program.

I think this should be the case, since it is a compile error, rather than linking error
Warnings - obj file generated
Error - no obj file generated

And you are right.
Checking the line number and error code can lead to a solution.
Yet, the actual compiler error that is listed by line number can be from some other problem with the code in another line number, in this situation just nearby in line 6. At other times the problem code can be several lines away, which can be frustrating to locate.

 

[sysprog]

I think this should be the case, since it is a compile error, rather than linking error
Warnings - obj file generated
Error - no obj file generated

And you are right.
Checking the line number and error code can lead to a solution.
Yet, the actual compiler error that is listed by line number can be from some other problem with the code in another line number, in this situation just nearby in line 6. At other times the problem code can be several lines away, which can be frustrating to locate.

If it's an error (without debug file creation turned on), so that no object file is stored, how does the linker then link the (nonexistent) object file into the .exe file?

 

[Mark44]

Didi you mean to say that the .exe file would not be generated? (unless it's a debug version) why would an object file be created and then linked into "an .exe file" if the compiler reported an error? I think that you're better at this stuff than I am, @Mark44; would you please clarify this?

Yes, that's exactly what I meant but somehow omitted "not". I have edited my earlier post, but not what @sysprog copied. Also, providing there are no compile or link errors, an .exe is generated whether the program is in debug mode or release mode. You can run either of them from a command prompt window separate from the VS IDE.
@yungman's statement confuses me:

And when I choose run anyway, the error is:

I don't see how he could run the code if a compiler error was produced, for precisely the reason you mentioned.

 

[Mark44]

I think this should be the case, since it is a compile error, rather than linking error
Warnings - obj file generated
Error - no obj file generated

Sorry for any confusion -- I meant that with compile errors, and .exe would not be generated, but somehow omitted that crucial word. I have edited my earlier post.

Checking the line number and error code can lead to a solution.
Yet, the actual compiler error that is listed by line number can be from some other problem with the code in another line number,

Right, but the most obvious place to start looking is at the line that was listed.

 

[sysprog]

Also, providing there are no compile or link errors, an .exe is generated whether the program is in debug mode or release mode.

Yep. I was right. You do know this stuff better than I do.

 

[sysprog]

@yungman's statement confuses me:
I don't see how he could run the code if a compiler error was produced, for precisely the reason you mentioned.

I think that sufficiency of version control may be at issue.

 

[sysprog]

I don't want to say the book is wrong, but I find it fishy on line 18.

I think that the book's line 11:
bool openFileIn(fstream &, char *);
is not incompatible with the book's line 18:
if (!openFileIn(dataFile,"demofile.txt"))

It seems to me that the book's line 18 is checking whether it is not the case that the text file is present and open.

 

[256bits]

If it's an error (without debug file creation turned on), so that no object file is stored, how does the linker then link the (nonexistent) object file into the .exe file?

Doesn't an error mean that the code is not fit for compilation?

Debug would be to see where your exe file is giving incorrect results ( example - maybe you expect it to print out a 6 and the program prints out an 8 instead ) when running.

 

[256bits]

Yep. I was right. You do know this stuff better than I do.

Of course you are right.
@Mark44 gives fantastic answers regarding coding.

 

[Mark44]

Doesn't an error mean that the code is not fit for compilation?

A compile error means that no .obj file is created. A link error means that an .obj file was created, but an .exe file could not be created.

Debug would be to see where your exe file is giving incorrect results ( example - maybe you expect it to print out a 6 and the program prints out an 8 instead ) when running.

Both debug mode and release mode create .exe files, provided there were no compile or link errors. Debug mode causes extra instructions to be inserted so that you can single-step through the code in the debugger - that's my understanding anyway.

 

[yungman]

I think that the book's line 11:
bool openFileIn(fstream &, char *);
is not incompatible with the book's line 18:
if (!openFileIn(dataFile,"demofile.txt"))

It seems to me that the book's line 18 is checking whether it is not the case that the text file is present and open.

Sorry, I deleted the post as I want to do more research on line and check other books. But I still cannot get the answer. I am going to post this again.

I don't follow what you said, "line 11 is not incompatible with line 18", do you mean they are compatible as "not incompatible"?

 

[yungman]

I have a new question, This is straight out of the book and I spot something that is very questionable. It is on Page 661 and 662 of this book, Program 12.5. This is the link of the Gaddis book I am using. You can see in page 661, there should be a videonote...that I don't have. So I might be missing something.
https://cplusplushelp.weebly.com/uploads/2/5/6/5/25655197/0136022537.pdf

My question is on line 18. if(!openFileIn(dataFile, "demofile.txt")). If you look at line 11 bool openFileIn(fstream&, char*); The second argument is a char pointer. That doesn't match line 18.

I typed it in VS, it did flag me even before running the compiler as it should. This is my code that I typed in just in case you want to take it out to try it. My eyes is not that good, I checked, it should be the same as in the book EXCEPT on some '\n' in the count statements AND I skip all the comments. I like to have more space between lines.

I also look into other textbooks I have and went online. I cannot find the answer.

//12.5 fstream pass by reference to function
#include <iostream>
#include <fstream>
using namespace std;

const int MAX_LINE_SIZE = 81;
bool openFileIn(fstream&, char*);
void showContents(fstream&);

int main()
{
    fstream dataFile;
    if (!openFileIn(dataFile, "demofile.txt"))
    {
        count << " Fileopen error! \n\n";
        return 0;
    }
    count << " File opened successfully.\n\n";
    count << " Now reading data from file.\n\n";
    showContents(dataFile);
    count << " done.\n\n";
    return 0;
}
bool openFileIn(fstream& file, char* name)
{
    file.open(name, ios::in);
    if (file.fail())
        return false;
    else
        return true;
}
void showContents(fstream& file)
{
    char line[MAX_LINE_SIZE];
    while(file >> line)
    {
        count << line << endl;
    }
}

I don't want to say the book is wrong, but I find it fishy on line 18. I am going to try writing the program on my own, I am not sure you need a pointer for this. All they want is to create the file in the function openFileIn and return the file name.

Thanks

 

[256bits]

A compile error means that no .obj file is created. A link error means that an .obj file was created, but an .exe file could not be created.

Yes that is what I meant for a compiler error - the code does not compile ".
I hope it is clear now for everyone.

 

[yungman]

This is my version of passing fstream to function, open and read content.

//12.5 fstream pass by reference to function
#include <iostream>
#include <fstream>
using namespace std;

const int MAX_LINE_SIZE = 81;
bool openFileIn(fstream&);
void showContents(fstream&);

int main()
{
    ofstream outFile;
    outFile.open("demoFile.txt");
    outFile << "This is a test.\n\nAnother test";
    outFile.close();
    fstream dataFile;
    char name[81];
    if (!openFileIn(dataFile))
    {
        count << " Fileopen error! \n\n";
        return 0;
    }
    count << " File opened successfully.\n\n";
    count << " Now reading data from file.\n\n";
    showContents(dataFile);
    dataFile.close();
    count << " done.\n\n";
    return 0;
}
bool openFileIn(fstream& file )
{

    file.open("demofile.txt", ios::in);
    if (file.fail())
        return false;
    else
        return true;
}
void showContents(fstream& file)
{
    char line[MAX_LINE_SIZE];
    while (file >> line)
    {
        count << line << " ";
    }
    count << "\n\n";
}

I have not double check my work, but it works, I don't even need the second argument passing to function.
I added few lines in the beginning of main to create the file "demofile.txt" so I can read back from the program. It's NOT even hard to code! Like 15 minutes to fix the original code.

If this looks ok to you guys, I am going to move on. I want to finish this book. Between the stupid mistake I made in the "int main()" and this, my whole day yesterday was a total waste.

Thanks

 

[Mark44]

Regarding your post #19:

I don't want to say the book is wrong, but I find it fishy on line 18.

Line 18 is a count statement. Do you mean line 13?

My question is on line 18. if(!openFileIn(dataFile, "demofile.txt")). If you look at line 11 bool openFileIn(fstream&, char*); The second argument is a char pointer. That doesn't match line 18.

Again, this is line 13, and the prototype for openFileIn() is on line 7, not line 11.

I am not sure you need a pointer for this. All they want is to create the file in the function openFileIn and return the file name.

Yes, the second argument needs to be a pointer if the argument is a C-string. The parameter is of type char *; the actual argument, "demofile.txt", is of type const char *. There is a bit of type coercion going on here. You could just as well declared the function this way: bool openFileIn(fstream&, const char *); .

Also, your openFileIn() function does not return the file name -- it returns a bool.

Regarding your post #21, your new version of openFileIn() is not as good as the previous version, since the filename is hardcoded in the body of the function. The previous version allows the filename to be passed to the function, so the program could conceivably ask the user to enter the filename at run time.

If this looks ok to you guys, I am going to move on. I want to finish this book.

Before moving on, I would advise that you go back and work with pointers some more. There is a fair amount that you don't understand; namely, the type of a string literal (e.g., "demofile.txt"). Several posts in this thread indicate that you don't have a clear understanding in this area.

 

[yungman]

Regarding your post #19:
Line 18 is a count statement. Do you mean line 13?
Again, this is line 13, and the prototype for openFileIn() is on line 7, not line 11.

Yes, the second argument needs to be a pointer if the argument is a C-string. The parameter is of type char *; the actual argument, "demofile.txt", is of type const char *. There is a bit of type coercion going on here. You could just as well declared the function this way: bool openFileIn(fstream&, const char *); .

Also, your openFileIn() function does not return the file name -- it returns a bool.

.....

I still need to read the rest of your comments, the line number is STRAIGHT from the book, not the code I posted. I don't trust my copy 100%, this is too important, I was talking about page 661 in the book. I gave the link to the book in my post, just click and go to page 661.

Thanks

 

[jtbell]

My question is on line 18. if(!openFileIn(dataFile, "demofile.txt")). If you look at line 11 bool openFileIn(fstream&, char*); The second argument is a char pointer. That doesn't match line 18.

The version of C++ that Gaddis used apparently accepts literal strings (e.g. "demofile.txt") as compatible with char*. The compiler allocates a chunk of memory to contain the string, and generates a pointer to pass to the function.

In its default mode, my compiler compiles this program, but generates a warning for the if-statement: conversion from string literal to 'char *' is deprecated.

When I tell my compiler to use the C++11 standard, it generates an error: ISO C++11 does not allow conversion from string literal to 'char *'.

This is because a function can modify a pointer that is passed to it as char*, which shouldn't make sense for a string literal. OpenFileIn() doesn't actually modify the pointer, but in principle it could, which is what matters. I can remove the warning and error messages by making that argument const char*:

// prototype line before main()
bool openFileIn(fstream&, const char*);
// beginning of the actual function
bool openFileIn(fstream& file, const char* name)

 

[Mark44]

I still need to read the rest of your comments, the line number is STRAIGHT from the book, not the code I posted.

When you post code here, the lines are numbered. Please don't expect any of us to open the link to the book, and pore through it to find the page to see which line you're talking about.

 

[yungman]

When you post code here, the lines are numbered. Please don't expect any of us to open the link to the book, and pore through it to find the page to see which line you're talking about.

I link the book because I don't want to miss interpreted the book, it's the book I question. I did say the code is only if anyone want to try it.

 

[Mark44]

I link the book because I don't want to miss interpreted the book, it's the book I question. I did say the code is only if anyone want to try it.

That's fine, but if you post code and it shows line numbers, those are the line numbers you should talk about.

 

[jtbell]

You can eliminate the separate function that opens the file and tests whether the opening succeeded by using the following technique:

//12.5 fstream pass by reference to function
//Modification: opens the file when the fstream is declared,
//so we can more easily test whether it was successful.
#include <iostream>
#include <fstream>
using namespace std;

const int MAX_LINE_SIZE = 81;
void showContents(fstream&);

int main()
{
// Declares the fstream variable and initializes it by opening the file.
    fstream dataFile ("demofile.txt"); 
// If you use an fstream variable as if it were a bool, it evaluates as true or false
// depending on whether the previous operation on it succeeded.
    if (!dataFile)
    {
        count << " Fileopen error! \n\n";
        return 0;
    }
    count << " File opened successfully.\n\n";
    count << " Now reading data from file.\n\n";
    showContents(dataFile);
    count << " done.\n\n";
    return 0;
}

void showContents(fstream& file)
{
    char line[MAX_LINE_SIZE];
    while(file >> line)
    {
        count << line << endl;
    }
}

 

[sysprog]

When you post code here, the lines are numbered. Please don't expect any of us to open the link to the book, and pore through it to find the page to see which line you're talking about.

Yes $-$ I at first thought that the line numbers were in reference to the code posted here, and misinterpreted because of that, and later edited my post accordingly $-$ I think that it's better to distinguish explicitly what's being referenced.

 

[jtbell]

Note this program reads one word at a time, not one line at a time. If there are blank spaces on a line (i.e. multiple words), it writes each word on a separate line. To read and write each line intact, use getline(), and preferably std::string so you don't have to worry about how long the lines might be.

//12.5 fstream pass by reference to function
//Modification: opens the file when the fstream is declared,
//so we can more easily test whether it was successful.
//Modification #2: use getline() for input so we can read
//spaces, too.
#include <iostream>
#include <fstream>
#include <string>
using namespace std;

void showContents(fstream&);

int main()
{
    fstream dataFile ("demofile.txt");
    if (!dataFile)
    {
        count << " Fileopen error! \n\n";
        return 0;
    }
    count << " File opened successfully.\n\n";
    count << " Now reading data from file.\n\n";
    showContents(dataFile);
    count << " done.\n\n";
    return 0;
}

void showContents(fstream& file)
{
    string line;
    while (getline (file, line))
    {
        count << line << endl;
    }
}