If you get that compile error, it means precompiled headers are enabled and if so, then you must add #include "stdafx.h" to the beginning of every source file.
There are probably other errors (related to the actual code example), but I can't help you with that.
Originally Posted by Adak
I understand... Thanks for your time and help. I appreciated it !
Just in case it's not clear, this is a compiler set-up problem. A properly installed & configured compiler should always be able to find <fstream>. And FYI - stdafx.h is Microsoft-specific... It's not standard C++. (Compilers are always a pain to configure.)'#include <fstream>': skipped when looking for precompiled header use
Add directive to 'stdafx.h' or rebuild precompiled header
If you are using Visual C++ Express, you may need to download the Platform SDK and follow these instructions.
And, when you create a new Visual Studio project, you need to select the correct project type (Win32 Console application, Win32 GUI application, .Net application, etc.).
I would turn off pre-compiled headers rather than add the #include "stdafx.h" to each source file. You probably don't need them for small projects. The option is probably under the Project Properties.
When creating a new project, check the Empty Project option under Application Settings after creating a Win32 Console Application.
I wouldn't recommend turning them of at all. They don't hurt performance and they can help performance later.
And fstream is an STL header, is it not? In that case, the Platform SDK is not necessary; it's just that the PCH was not included at the beginning of the file. A simple mistake, a simple fix.
>> I wouldn't recommend turning them of at all. They don't hurt performance and they can help performance later.
Again, hasn't this been discussed before? What is your counter-argument for the fact that precompiled headers are not portable, they are completely unnecessary for simple programs, and they tend to confuse beginners?
We have
Erm, so even if they can't be used on all compilers, they're just headers. Just an additional header to include. Sure, you won't get the same speed, but it still works just as well.
Doesn't mean you have to turn them off, however. There is no good reason for doing so.
If they get "did you forget to include 'stdafx.h'" error then I believe that we can teach them how to use them. It doesn't hurt! Just add '#include "stdafx.h" to every source file and you have no problem!
We don't necessarily have to teach them to stuff all their headers into stdafx.h; that can come later, but just for the sake of it, why not teach them how to avoid the compile error the real way rather than disabling them?
What reasons have you for disabling them? Do they somehow hurt performance? No. Then don't disable them!
>> What reasons have you for disabling them?
The only benefit to using them in this case would be to learn how to use them in case you will be working on large projects with Visual C++ in the future. That is a very minor benefit because many people asking questions here will never go on to work on a large project in VC++, and those that do will easily be able to learn how precompiled headers work at that time.
One reason to disable them is that they add complexity to the program. In this case, the program consisted of a single source file. Adding another file to the project to maintain is significantly more complex relative to not doing so.
Another reason to disable them is portability. The stdafx.h file is generated automatically by VC++ when you have precompiled headers turned on. If you try to post your code in a forum, or move to another compiler, you must remember to post the contents of that file or copy that header file to your new environment. Then, as you said, it is just a regular header file that adds unnecessary complexity.
So basically you have one tiny potential pro and two real cons. The choice seems obvious to me. Especially when working with beginners, and especially when the benefit is small (if there is one at all) choose simplicity over complexity.
If it's a single source file, it's probably flawed to begin with. As both of us know, all prototypes should go into a header; this is something we really should teach because it's standard practice, at least later when they begin to go multi-file. So if they already have include headers... what's one more?
But then again, you have to copy the contents of any header you yourself created to show. And you do copy all the source files when copying a project, do you not?Another reason to disable them is portability. The stdafx.h file is generated automatically by VC++ when you have precompiled headers turned on. If you try to post your code in a forum, or move to another compiler, you must remember to post the contents of that file or copy that header file to your new environment. Then, as you said, it is just a regular header file that adds unnecessary complexity.
I understand that it may add a little extra step, but I don't consider is a con to disregard PCH altogether.
From my side, it seems like it neither has pros nor cons.So basically you have one tiny potential pro and two real cons. The choice seems obvious to me. Especially when working with beginners, and especially when the benefit is small (if there is one at all) choose simplicity over complexity.
>> If it's a single source file, it's probably flawed to begin with.
In this case, you posted the code. So if you think that single source code is flawed, then why post it? The reason is of course that single source code is not flawed and your example was fine. It is perfectly acceptable and in fact desired for beginners to use a single source file. Anything more adds unnecessary complexity.
For whatever reason you don't seem to consider unnecessary complexity a bad thing. If you want to use precompiled headers for your projects that's fine. I use them in many of mine. But they are unnecessary and detrimental to a beginner trying to learn C++, so they should not be used and should not be encouraged at that level.
But my point is, while you shouldn't encourage them, you shouldn't discourage them either!
Instead of "you have PCH on, disable it," you could go like "It looks like you have PCH on, this may not be required for such small projects and especially not beginner projects; so if you don't want an explanation of what they are, then you can disable them and you won't have to do '#include "stdafx.h"' in every source file."
And also, it's fine to merge the code when posting, but in your IDE, IMO, it's better to always put prototypes in a header.
No, they add unnecessary complexity. They should be discouraged for beginner programs.
Also please re-read my original post on the subject. It sounds an awful lot like what you're suggesting.
>> And also, it's fine to merge the code when posting, but in your IDE, IMO, it's better to always put prototypes in a header.
You think a hello world program should have a header file? Your code doesn't have any user created prototypes, so what exactly would go in the header?
It seems our views differ then.
I do not think they add unnecessary complexity - because there isn't much that can go wrong, other than the compile error that's easily fixed, of course.
If there's no prototypes, there's no need for any headers either. Simple as that!>> And also, it's fine to merge the code when posting, but in your IDE, IMO, it's better to always put prototypes in a header.
You think a hello world program should have a header file? Your code doesn't have any user created prototypes, so what exactly would go in the header?
If your code needs "stdafx.h", you are not making a console program --- you're making a windows program. Make a new project and after you have entered the test code from Elysia, make sure that you "Add" that file to your Project (under the Project tab).
>> If there's no prototypes, there's no need for any headers either. Simple as that!
Exactly. So what are you disagreeing with? In this thread, the code that gave the problem (that you wrote) had no prototypes. Therefore, there is no need for any headers and no need for precompiled headers.
