I'm working on a project in Visual Studio 2010. My project is not supposed to be limited to Windows, however, one of the files is OS-dependant.
For this reason, I have #include <windows.h> in only one of the .cpp files. No other file includes this .cpp files. Therefore, logically, the windows.h header should be invisible to the rest of the solution.
This means that I don't have any name conflicts with declarations in the Windows library in all files but that one .cpp, and my project compiles just fine.
However, IntelliSense keeps on insisting that I have name conflicts. When I press Ctrl+Space, IntelliSense suggests identifiers from windows.h. And this is in the scope where windows.h should be invisible!
Is there a setting I can change to stop this annoying behaviour?
I'm 100% positive that the issue is not with the structure of my solution because if I use an identifier already defined in windows.h in another part of my project, the compiler does not recognize it and it doesn't compile...but IntelliSense recognizes it!
Quoting Andy Rich, a Microsoft employee who works on VC++, from a comment on this blog article: Troubleshooting Tips for IntelliSense Slowness
The browsing database will find all source files that are somehow included in your project, either directly or as a result of other #include directives. This is not configurable, and is necessary in order for the IDE to be able to provide accurate answers.
So unfortunately the answer is no, there's nothing you can do beyond disabling IntelliSense altogether.
Since IntelliSense works on a per-project base (.vcproj), not per-solution (.sln), the easy answer is to move the Windows-specific parts to their own project within your solution.
This also helps with porting, as you can more easily replace the Windows-specific parts.
Related
So I have a CMake project which I open in Visual Studio 2019 with the "Open Folder" option. From here I can build and compile it without any errors (CMake is using the IAR Compiler (iccarm.exe) as specified in the toolchain file). So far so good.
The problem is that IntelliSense, despite finding all necessary header files, shows lots of errors mainly related to "undefined __INTxx_T_TYPE__".
As far as i know thouse double underscores indicate that it's a compiler internal data type, which is not defined in any header file, which would also explain why IntelliSense reports that it's not defined (even if the compiler knows the type). I guess to counter this problem, IntelliSense does support different modes like "windows-msvc-x86" or "linux-gcc-arm". But there is no option for IAR compiler.
So my question: How can I get IntelliSense running in this project ? Is there a way to add a custom IntelliSense mode for the IAR compiler ? Can i add header files only for IntelliSense in which the missing types are defined ? Is there a way to tell IntelliSense not to worry about those types / ignore the types ?
Ok just for the unlikely case someone has the same problem, here is my "solution" (sort of):
I created a header file with all the internal types used by IAR and called it "intellisenseHeader.h". You can find the internals here (https://www.gaio.co.jp/support/user/faq/winams/docs/sample_predef.pdf), but in my case i had to add some definitions by myself. The problem is now, that it won't compile anymore, because the IAR compiler, now finds 2 definitions (the internal definition and the one in the header file). So we need to fix this again:
I put the include inside a #ifdef USE_INTELLISENSE_HEADER.
I created two Visual Studio configurations. In the first one, CMake will set the preprocessor directive and the intellisenseHeader file will get included. In the other one i didn't set it.
So what's the effect of this ? If you are in the configuration, where the header is included, IntelliSense works but you can't compile. And if you are in the other one you can compile, but IntelliSense doesn't work anymore. So now i need to switch between the configurations, everytime i want to compile or write some code... Not the best solution but still better than nothing.
EDIT: Ok just realized you can use __INTELLISENSE__ as mentioned in # Richard Critten comment, and therefore don't need to use multiple configs.
I have noticed some odd behaviour in VS2012 while working with some C++ projects. If I put the following line at the top of a header file: (myclass.h)
#include <D3DX11.h>
The compiler will tell me that it can't find the file (even though intellisense suggests it). However, if I put the same line in a different file (myclass.cpp) everything works just fine. I don't understand why it can be found when used in one file, but not the other? What is going on ?
EDIT / NOTE:
This isn't really a DirectX specific issue. That is just what I was working with when I decided to ask. This can happen in other places as well.
In the newer versions of visual studio the include paths are set at project-level. Maybe the project containing the cpp has the proper path set (see the comment from Jesse Good in your question). However that might not be the case for another project in your solution. As soon as you put the include in the header, all other projects including your header will need to know where to find the directX-headers as well.
Beware of intellisense - if you open a header it has to guess what cpp you might include this header from and the displayed info is not always correct. I think in the newer versions it even depends on what other files are opened / project is selected.
The compiler should inform you what cpp actually causes problems when including the header.
I recently switched to Visual Studio 2010 and for Intellisense not to take half a minute to show up when using boost libraries, Microsoft's suggestion seems to use precompiled headers.
Except that I never used them before (except when forced to by Ugly ATL Wizards (TM)), so I searched around to figure out how they work.
Basically, the Big Centralized stdafx.h approach seems plain wrong. I never want to include (even cheaply) a whole bunch of header files in all my sources. Since I don't use windows libraries (I make C++/CLI higher level wrappers, then use .NET for talking to the outside world), I don't have "a whole truckload of non-changing enormous headers". Just boost and standard library headers scattered around.
There is an interesting approach to this problem, but I can't quite figure out how to make this work. It seems that each source file must be compiled twice (please correct me if I'm wrong): once with /Yc and once with /Yu. This adds burden on the developper which must manually tweak the build system.
I was hoping to find some "automatically generate one precompiled header for each source file" trick, or at least some "best practices", but most people seem happy with including the world into stdafx.h.
What are the options available to me to use precompiled headers on a per source file basis ? I don't really care about build times (as long as they don't skyrocket), I just want intellisense to work fast.
For starters, you are reading the article wrong. Every file is NOT compiled twice. The file stdafx.cpp gets compiled once with /Yc (c, for create) before anything else and then every other file in your project gets compiled once with /Yu (u, for use) and imports the result of the previously created saved state from stdafx.cpp.
Secondly, the article is 7 years old and is talking about VC++ 6, so you should start off distrusting it. But even assuming the information in it still applies to VC++ 2008 or 2010, it seems like bad advice. The approach it recommends using /pragma hdrstop is solution looking for a problem. If you have headers that contain things you don't want in every file, then they simply shouldn't go in your pre-compiled header.
Your problem basically seems to be that Intellisense is slow for Boost in VS2010? I don't have a direct solution for this problem, but could Visual Assist X be an option for you? I have used it in various versions of Visual Studio now and with great pleasure. Not a direct solution, but it might work for you.
Precompiled headers aren't too bad if you use them properly.
Don't use them as a replacement for proper and precise #includes, but as a way to speed things up. Achieve this by making the precompiled header do nothing in release builds, only speeding stuff up in debug.
You are wrong, each file is only compiled once. You have one .cpp file that is compiled with /Yc and the rest are compiled with /Yu. The file with /Yc, which is stdafx.cpp by default, contains one line, #include "myMainHeader.h" (changed the name from the default) All other .cpp files must start with #include "myMainHeader.h" When your /Yc file is compiled, the entire internal state of the compiler is saved. That file is loaded when each of your other files is compiled. That is why you must start with including the PCH, so that the /Yu option doesn't change the result of compilation, only the time. Xcode does not make this requirement and will use a PCH regardless of if your .cpp file starts with the right include directive. I have used libraries that relied on this and could not be built without PCH.
I'm a beginner starting to use Microsoft Visual C++ Express 2010 for Windows Programming. I've created a new C++ application using native code, not managed or MFC. I had Visual Studio create for me the basic windows code to create one window with simple menus (chat.cpp). I modified this file and I was able to compile correctly and see my changes take effect.
Now I've added one more source file to the solution (intro.cpp) which I include in my header and call from within chat.cpp. This seems to work just fine, but with one problem. The compiler doesn't seem to be applying my code changes occasionally: I make various edits, recompile, and the "old" code seems to be running. Then, after a while, after I make only a tiny modification, the compiler seems to "catch up" and it runs the new code including all the previous changes I had made.
Is there some kind of cache? Do I need to tell the compiler which files to compile and which ones to just link from object files? Did I make a mistake when I added the file to the solution?
Does intro.cpp have a header file? is that in your solution too?
It's hard for me to imagine that this area of such a mature IDE has a bug here, so I would examine your file list first. Make sure that the Solution Explorer shows all the files you have added and are editing. This is the list that VS uses to determine rebuild is needed.
EDIT: I admit it's not clear to me from your description why it would fail right now. However, typically header files do not include code, it works the other way around (except for class template header files, such as the STL headers). There is some discussion about pros and cons here. The most compelling argument to me in favour of code including headers rather than vice versa is that the header file contains the interface, while the code file contains the implementation.
I would try restructuring your code to a more traditional structure where intro.cpp includes intro.h and any others it needs, and the same with chat.cpp. Then your compilation units are intro.cpp and chat.cpp, and they depend on the associated header files, so provided they are properly listed in the SOlution Explorer, all should work. You can clean up the build dependencies to avoid dups and reduce build time once you have it working as you wish.
I have just come across a Visual C++ option that allows you to force file(s) to be included - this came about when I was looking at some code that was missing a #include "StdAfx.h" on each .cpp file, but was actually doing so via this option.
The option can be found on the Advanced C/C++ Configuration Properties page and equates to the /FI compiler option.
This option could prove really useful but before I rush off and start using it I thought I'd ask if there are any gotchas?
I would say the opposite to litb above if you're using precompiled headers. If you use "stdafx.h" as your precompiled header and have code like this:
#include "afile.h"
#include "stdafx.h"
then you'll be spending an age trying to figure out why "afile.h" isn't being included. When using precompiled headers, all the includes and #defines are ignored up to the "stdafx.h". So, if you force include the "stdafx.h" then the above will never happen and you'll get a project that uses the precompiled option efficiently.
As for litb's comment about finding macros, good IDE's usually have an option to jump to the definition of a symbol, whether it be a #define, function, class, etc.
I would discourage from /FI (MSDN says it's called /FI . Not sure whether i looked at the right page though), simply because people or yourself reading the files don't notice a header is magically included anyway.
You can be sure this will cause much debugging time for someone that wants to figure out where specific macros come from, even though there are no #include lines at the top of the file.
Force includes is also helpful for automatically generated source files. Our system uses a tool that generates many source files but they don't include our pre-compiled header file. With "force includes" compilation of these files is now faster.
Optionally, it would be possible to write a script to insert the #include line in those files after generation and before compilation. But why go to that trouble?
I'd side with litb: don't do the forced includes. Having the code be explicit makes it easier to know what's going on for a new user. It also makes it easier to know what's going on if you ever need to port the code to a new platform.
Note that if the code uses templates, Visual Studio usually can't track down the definitions correctly. Perhaps 2010 will be better, but even VS 2008 is problematic on this front.
I wouldn't use it that often but it has its uses. I have used it to add a header that suppressed some warnings to all cpp files so that I could turn on /W4 or /Wall for the project and not have to edit all of the cpp files to include the warning suppression header first. Once eveything was working I DID go back and edit all the cpp files but for a proof of concept /FI was useful.
Likewise you can use it to force a precompiled header into cpp files in some build configurations but not in all (in case you want to have a build configuration that DOESNT use precompiled headers and that makes sure that each cpp only includes exactly what it needs to). However using #pragma hdrstop is, IMHO, a better way to achieve this.
I've talked about all of this on my blog here: http://www.lenholgate.com/blog/2004/07/fi-stlport-precompiled-headers-warning-level-4-and-pragma-hdrstop.html in a little more detail.
Save this function for when something weird comes up - like if you want to include a header in a generated source file. Even then there are likely better ways.