|
Like stated before, the actual path to the file is probably not correct. I was having this issue when including stdafx.h from a cpp file in a subdirectory. It would compile just fine, but intellisense didn't like it. Ofcourse it complained about the missing header file when i turned pch's off. I ended up adding $(ProjectDir) to the additional include directories field, since this is where stdafx.h is. I'm surprised though that this folder is not in the include path by default.
Edit: I should mention though that there was a bug related to this very thing, where intellisense still would not pick it up. If you install SP1, this bug is fixed, and adding the path to your additional includes works (for example $(ProjectDir))
|
|
|
|
|
...and it is true that you can specify the file name, in your project settings, although intellisense isn't as smart as the compiler in finding this file...and that's the whole point, that MS created these two products with different logic
|
|
|
|
|
sorry but i'm not about to download a zip file from the internet
|
|
|
|
|
Unfortunately, successful compilation does not imply well-formed C++ code. Even C++ Standard explicitly allows implementations to not produce any diagnostic in many cases, just look up the “no diagnostic is required” in your copy of ANSI C++ Standard.
PCH implementation in Visual Studio is very straightforward. The compiler searches for an occurrence of a magic string (ignoring case and whitespaces). After magic string is found, compiler internal structures are initialized with stored state which was obtained during compilation of StdAfx.cpp.
This means that magic string does not have to include any really existing file. Instead of #include “StdAfx.h” it can be something like #include “Nonsense.h” and it will perfectly compile. The only requirement is that this magic string must match PCH project settings. As you are not going to believe me I prepared sample VS2010 project, you can get source code here http://www.lanovets.ru/temp/testpch.zip and try to explain why it compiles  Just look at the file Test.cpp in the sample.
Again, turning PCH off will break compilation, so the program is ill-formed.
|
|
|
|
|
|
The problem is that this is not a valid C++ program. There is no "./StdAfx.h" file, so it should not compile. In fact, when you turn off PCH in project settings, the program won't compile.
Moreover, the solution requires adding two lines instead of one into every cpp file.
Just adding StdAfx.h to every subfolder requires less code, does not invalidate C++ program and makes both compiler and Intellisense happy.
Microsoft is correct here, Intellisense is not required to parse invalid programs. The correct solution for Microsoft is to stop compiling invalid programs and produce an error.
Unfortunately, compiler cannot detect this error in the program for free because this will undermine the whole idea of PCH. The idea of PCH is to skip everything prior to some magic string in CPP file. When PCH is on, compiler does not try to include StdAfx.h at all, compile simply ignores that line and nearly anything that was in the file before that line.
|
|
|
|
|
Since this was moved and posted as a comment, I'll answer again.
This is a very bad observation,
1) It is a valid vc++ program, it DOES COMPILE.
2) File #include "..\\stdafx.h" DOES EXIST, its #include "stdafx.h" that doesn't really exist, but the vc++ compiler insists on having that line to use PCH.
3) Adding stdafx.h to every subfolder is a dirty solution, polluting your subfolders with files that you don't really need.
4) This is NOT an error, its a solution to how MS does things. You don't understand PCH, read up on it sometime.
In the future, read things more carefully before commenting with non-sense.
|
|
|
|
|
Albert, I think your reply to Xentrax was hasty. In fact Xentrax's comment was that the file "./stdafx.h" or in other words stdafx.h in the CURRENT directory does not exist. Xentrax was correct in saying the file should not compile. You will see that all other include files must include the path if they are located in the parent directory or any other directory that is not in the include path. The pch file unfortunately gets special handling. Enabling pch's will allow the compiler to compile technically incorrect code.
|
|
|
|
|
Not hasty at all, he doesn't understand what he's commenting about. As far as PCH getting different treatment from the compiler... hence the article...
|
|
|
|
|
What if you had a dummy stdafx.h which had one line:
#include "..\stdafx.h"
|
|
|
|
|
that would work too... but its adding a file versus adding a line... i like a line..
|
|
|
|
|
Wait. Don't you already have two stdafx.h files? One in project directory (stdafx.h) and one in parent directory (..\stdafx.h)?
|
|
|
|
|
No, that's the whole point... re-read the article.
|
|
|
|
|
or maybe i didn't make that clear enough... ???
|
|
|
|
|
Not with PCH; it's a bit weird in that respect. We've looked at it in some detail while working with PC-lint 9.0 PCH support, and the logical rules you have to follow when stdafx.h is in a non-default location are odd to say the least.
Of course if you port a VC++ project which uses PCH to another compiler you'll need to have multiple copies of stdafx.h as you describe - but that's the subject of another article (once I get my act together...)
Anna ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
...unless the other compiler actually supports just specifying the exact location of the PCH... or alternatively, their intellisense equivalent supports the same auto-disambiguation as the compiler...
|
|
|
|
|
In this case it's GCC under Eclipse/CDT so PCH isn't supported.
That's not to say that you can't use PCH files - it's just that they have to be reachable via the project include path rather than PCH magic. In our particular case we had to include a stub stdafx.h file in a couple of places to keep GCC happy, whereas VC++ would just find he main one via the project PCH properties.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
unrelated question... How do you like Eclipse/CDT? Its always a bit odd for me to use a JVM to make C/C++.
|
|
|
|
|
To be honest, I find it rather strange and much prefer my everyday VS2008 + Visual Assist setup. It also seems far slower to start than even VS2010, and that has to be quite some achievement!
We've recently released a Visual Lint plug-in for Eclipse, which is the main reason why I'm spending a bit of time with it. All our production code is still written under VS2008 with WTL, although in time we're likely to migrate parts of that to a cross-platform implementation (which means more Eclipse, so I'd better get used to it!).
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Maybe you can try some other IDEs that aren't eclipse, its probably slow because it is Java based. I'll be eventually developing more cross-platform stuff, so its always of interest to me what people think of their IDEs.
|
|
|
|
|
Possibly - though based on the info we've seen recently Eclipse and Visual Studio dominate the market so completely that there are very few others with much of a foothold. As our main purpose in familiarising ourselves with Eclipse is to be able to support plug-ins for it, doing so has a diminishing return for environments which aren't heavily used.
Having said that, CodeGear C++ is one we also have to look at at some point, but quite honestly I can't see myself using it in anything other than a support capacity. SlickEdit is more interesting, but again relatively niche.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Eclipse does have a huge market share.
|
|
|
|
|
That's what I said. 
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
I was just agreeing
|
|
|
|
|
Sometimes it's hard to be sure on the web. 
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
