Mysterious error!

  • Thread starter yungman
  • Start date
  • #1
4,943
110
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.
C++:
#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 :
Compile error Listing 7.2.jpg

And when I choose run anyway, the error is:
Compile error Listing 7.3.jpg


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
 
Last edited:

Answers and Replies

  • #2
berkeman
Mentor
58,164
8,216
They are not exactly the same... :wink:
 
  • Like
Likes sysprog
  • #3
4,943
110
They are not exactly the same... :wink:
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.
 
  • #4
berkeman
Mentor
58,164
8,216
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.
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...
 
  • Like
Likes .Scott, jim mcnamara, sysprog and 1 other person
  • #5
4,943
110
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
 
  • Like
Likes sysprog and berkeman
  • #6
34,149
5,764
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.
 
Last edited:
  • Like
Likes berkeman and sysprog
  • #7
1,649
905
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?
 
  • #8
256bits
Gold Member
3,233
1,254
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.
 
  • #9
1,649
905
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?
 
  • #10
34,149
5,764
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.
 
  • Like
Likes 256bits and sysprog
  • #11
34,149
5,764
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.
256bits said:
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.
 
  • Like
Likes 256bits and sysprog
  • #12
1,649
905
Mark44 said:
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. :wink:
 
  • #13
1,649
905
Mark44 said:
@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.
 
  • #14
1,649
905
yungman said:
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.
 
Last edited:
  • #15
256bits
Gold Member
3,233
1,254
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.
 
  • Like
Likes sysprog
  • #16
256bits
Gold Member
3,233
1,254
Yep. I was right. You do know this stuff better than I do. :wink:
Of course you are right.
@Mark44 gives fantastic answers regarding coding.
 
  • Like
Likes sysprog
  • #17
34,149
5,764
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.
256bits said:
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.
 
  • Like
Likes sysprog and 256bits
  • #18
4,943
110
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"?
 
  • #19
4,943
110
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 cout statements AND I skip all the comments. I like to have more space between lines.

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

C++:
//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"))
    {
        cout << " Fileopen error! \n\n";
        return 0;
    }
    cout << " File opened successfully.\n\n";
    cout << " Now reading data from file.\n\n";
    showContents(dataFile);
    cout << " 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)
    {
        cout << 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
 
Last edited:
  • #20
256bits
Gold Member
3,233
1,254
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.
 
  • #21
4,943
110
This is my version of passing fstream to function, open and read content.
C++:
//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))
    {
        cout << " Fileopen error! \n\n";
        return 0;
    }
    cout << " File opened successfully.\n\n";
    cout << " Now reading data from file.\n\n";
    showContents(dataFile);
    dataFile.close();
    cout << " 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)
    {
        cout << line << " ";
    }
    cout << "\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
 
  • Like
Likes sysprog
  • #22
34,149
5,764
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 cout 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.
 
  • Like
Likes yungman
  • #23
4,943
110
Regarding your post #19:
Line 18 is a cout 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
 
  • #24
jtbell
Mentor
15,631
3,677
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*:

C++:
// prototype line before main()
bool openFileIn(fstream&, const char*);
// beginning of the actual function
bool openFileIn(fstream& file, const char* name)
 
  • #25
34,149
5,764
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.
 
  • Like
Likes Tom.G and sysprog

Related Threads on Mysterious error!

Replies
6
Views
2K
Replies
1
Views
7K
Replies
10
Views
8K
  • Last Post
Replies
4
Views
2K
  • Last Post
2
Replies
33
Views
8K
  • Last Post
Replies
7
Views
925
  • Last Post
Replies
3
Views
863
  • Last Post
Replies
3
Views
3K
  • Last Post
Replies
2
Views
4K
  • Last Post
Replies
8
Views
1K
Top