How to get IntelliSense to reliably work in Visual Studio 2008 - c++
Does anyone know how to get IntelliSense to work reliably when working in C/C++ projects? It seems to work for about 1 in 10 files. Visual Studio 2005 seems to be a lot better than 2008.
Edit: Whilst not necessarily a solution, the work-around provided here:
How to get IntelliSense to reliably work in Visual Studio 2008
Is probably the best bet if I want a decent IntelliSense system.
Native C++ intellisense does not work reliably in any version of Visual Studio. I find there are two common problems:
1) Header file paths are not set-up correctly. When you find a type where intellisense is not working, use the IDE to click through each header file to find the one containing the type. (Right click on #include and select Open Document...). If this fails before you get to the file which declares the type then this is your problem. Make sure header file search paths are set-up correctly.
And,
2) The intellisense database is corrupt. This happens ALL The time. You need to close the solution, delete the .ncb file, and then reopen the solution. I posted the macro I use for this in answer to another question here.
The preprocessor can also confuse intellisense - so make sure any #defines during build are also available to intellisense. Other than that, I don't know what else can break it. I've not seen any particular issues with forward declarations.
I've also realized than Intellisense is sometime 'lost', on some big project. Why? No idea.
This is why we have bought Visual Assist (from Tomato software) and disabled Intellisense by deleting the dll feacp.dll in the Visual studio subdirectory (C:\Program Files\Microsoft Visual Studio 8\VC\vcpackages)
This is not a solution, just a workaround.
It looks like there's hope on the horizon for those of us unable to obtain Visual Assist:
Rebuilding Intellisense
Do you have any add-ins installed (or uninstalled)? I find that effects my intellisense.
Besides that just making sure your Tools->Options->Text Editor->All Languages "Auto List Members" and "Parameter Information" are checked off.
I don't use VS2008 for C++, only VB & C#, but I find that when intellisense stops working (true for VS2003/2005/2008) it's because something in the project/file is broken - usually a bad reference or code.
VB and C# have much better intellisense support due to the ability to reflect on the referenced assemblies to build the intellisense tree.
C++ has to walk the include files for function prototypes, and if the paths are not correct it will not find all the prototype headers.
My fix to itellisense was required after that awful refactor utility minced my code. The problem was a class header file that included an #include of itself. The recursive reference destroys itellisense. A symptom of this is if itellisense can see other classes but not the current one. Also:
Use #pragma once to eliminate duplicate header loads
If the project now takes a very much longer time to load, that itellisense trying to make sense of the conflict that is causing then lack of completion support.
Often it is only one class object that is affected, This shows you what files (usually headers) to look at.
#John Richardson / #Jonathan Holland
My includes are setup correctly, no problems there. I've also tried the NCB rebuild several times but it never fixes it 100%.
I have a feeling it may be to do with forward declarations of classes. e.g. to reduce the complexity of includes in header files we normally do something like:
class MyPredeclared;
class SomeOtherClass
{
private:
MyPredeclared* m_pPointer;
}
I wonder if that screws it up? Any other ideas? It definitely gets worse the larger your project gets.
I had a very annoying problem, intellisense was working only in some files, without any evident reason... it took me a couple of hours of digging through google, but I finally understood that the reason was indeed recursive reference!
I was using the:
#ifndef CLASS_H
#define CLASS_H
...
#endif
to avoid redefinition of symbols, and this sometimes breaks intellisense in big projects.
But it is enough to comment the ifndef-define-endif and put a:
#pragma once
at the beginning of the header files to still avoid redefinitions and have Intellisense working again =)=)
At least, this worked for me, hope it's useful...
Cheers
Francesco
I have recently studied Intellisense in VS2008, as I'm developing a rather large C++ numerical linear algebra library where templates and such are used extensively. Intellisense stopped working shortly into the project and I sort of gave up, but now it became really annoying without it so I set to investigate. This is what I found out:
Assuming there is a file(s), containing code that "breaks" Intellisense,
if header files that break Intellisense are in the project, but are not #included, it still works in the rest of the files
if they are included, but no type declared inside is used, it still works
if they are included and a type declared inside is used, it might still work a bit (no Intellisense for members, no Intellisense after occurrence of given type, but at least global names and argument info before)
if Intellisense is broken in one .cpp file, it can still work in the others where the problematic code is not included or used (but i imagine if it crashes bad, it will get disabled for the whole project, although that did not happen to me)
Intellisense seems to be updated after successful compilation (sometimes not before)
putting broken code inside any of #if 0, /* .. */ or // seems to put Intellisense at ease
From the C++ features I used, actually only a few break Intellisense:
comparison with '>' or '>=' in template parameter (e.g. static_assert<(size > 0)>)
not solved by using double parentheses (static_assert<((size > 0))> does not help)
solved by using '<' or '<=' instead (static_assert<0 < size> works)
solved by storing the value in enum and using that to specialize the template
explicit function template specialization disables argument info (e.g. function<type>(args))
probably unable to solve (maybe wrap in a macro), but I can live with it being broken
instantiation of template member type, such as Matrix::MakeMatrixType<3, 3>::Result r;
kind of hard to figure out exactly why this happens (likely because of use of Eigen)
workaround by moving such code in a separate .cpp where IS won't work (not always possible)
It would seem that some of those problems are due to some "simplified" parsing, which is less strong than a proper C++ parser. With the above information at hand, a "reliable" method of making Intellisense work in an existing code:
Set up an empty project (a console app), create Main.cpp with dummy void main() {} in it.
Include one of your broken header files, and math.h
Build (it must compile, in order for Intellisense to update reliably)
Test whether Intellisense is working by typing e.g. sin( and seeing if argument help pops up. Sometimes, this would work, but member help wouldn't - so try that as well.
Make an instance of something in the header file, build, see if that manages to kill IS.
Remove code from the culprit file and go to step 3
After finding and fixing problematic code, put back code removed in step 5, try again
After making a whole class work well, make an instance of the next class, and so on ...
I found it easy this way to pinpoint locations of code that made problems (I realize that this might be unfeasible for really large projects, in my case only a single file out of 97 made problems). Note that 'Build' here refers to compiling, the linking stage does not need to finish, so unresolved externals are ok, the IS should update regardless.
Another method of updating IS (other than building) is to save everything, close workspace, delete .ncb file and reopen it. Then wait for 'Updating Intellisense ... (N)' to disappear from the status bar (N counts towards zero, if it doesn't go all the way, it kind of shows progress where problems occurred). I found this rather tedious.
About this problem i've notice something interesting (on Visual Studio 2010):
to solve this problem i've changed #include sintax in my header files, before was (old project done with VS 2005 and reopened using VS 2010):
#include <myfile.h>
and i fix this with:
#include "myfile.h"
After intellisense start working correctly!
I hope this can help!
I had to reset the settings...
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE>devenv.exe /ResetSettings
thread on this here
The problem is with the .vcproj files.
You will find if you switch to release mode from debug mode, build, then try intellisense it often works.
Close Visual Studio. If you search for the .vcproj files in your project, edit them and search for the first two instances of AdditionalIncludeDirectories. The value for this should look something like "..\,....\" rather than "../..".
Reopen your project, let the Intellisense finish building, then it should be fixed.
Related
Preprocessor definition cannot be identified in all project files for Visual Studio
I set preprocessor definition as follows: then Wrote the preprocessing codes in ConfigParamsHomog.h the macro RANSAC_EXPORT can be identified, while something different occured when rewriting above codes in HomogEstimator.h why the macro cannot be identified in HomogEstimator.h? to my understanding, the macro should cover the whole project once it added into the preprocessor definition.
This was (sort of) asked again 2 years later at Preprocessor definitions not working in VS2019 C++ . There were some good suggestions made (similar in both) but neither thread "closed out" in my opinion with a definitive answer. I read and confirmed I had all the suggested actions done, but still no joy. 'Someone' (somewhere else, sorry, I've lost the link) suggested that VS IntelliSense may not have been working properly in this situation. Taking this to heart I defined my symbol explicitly in the header file and rebuilt the project successfully. The next day I got messages saying that my symbol was being defined twice, so I pulled out the explicit definition and now all is working as expected! WTF? So, all I can really suggest is fudge the definition so that the project builds successfully and maybe, maybe, the problem will "fix itself". Not satisfactory, I know, but maybe my experience will help someone else :)
I stumbled into the same problem. What I did to fix the issue is make sure that the header file is getting included in the main.cpp file (the file that holds your main function). It appears global preprocessor definitions in headers won't work unless they get included into main.cpp.
Codeblocks can't find header files
So a few hours ago I started learning c++ in codelite but I was getting frustated with, so I just got codeblocks and imported the project. But now whenever I try to compile it returns: fatal error: imports.h: No such file or directory This is my project hierarchy in codeblocks: And this is what the project folder looks like: What am I doing wrong?
I know this is years later, but I've recently seen students following what I deem is frankly bad advice such as what is given above. For those learning c++ this functionality is NOT for you. To add headers you should simply check that you are using double quotes, instead of angled brackets i.e. #include "myheader.h" and NOT #include <myheader.h> Angled brackets are meant for libraries (informally) and adding a simple header file for you basic classes does not require you to change default search directories. The problem comes when someone else tries to run your code (assuming you're doing this for uni) and their IDE isn't setup to search for a "library" (your header) where it shouldn't be. Double quotes tells the compiler the files exist in your current relative directory. This way you can keep your main, headers and header implementation in one directory. Fiddling with your IDE should only be done when necessary. KISS
You have to tell Codeblocks where to find the header files that you include. Try adding the full path to your '/Headers' in the include directories of codeblocks Goto 'Codeblocks menu > Settings > Compiler > Search directories > Add'. EDIT: Since your issue, however, is quite irrelevant to learning the C++ language itself, I suggest that you start with simpler programs, then move on to more complex ones. That, of course, unless you have previous experience with other programming languages
Since I haven't found any Makro for #define 'hostname of device where compiler is located' // which is unique and not to be copied ! I have now successfully used and included #include "myCompileEnv.h" as a workaround with the comments above, which is located more central - above the project directories in CodeBlocks.
Show an error (in Visual studio), when someone tries to use STL in a current .cpp or .h file
In our company sometimes we write .cpp and .h files, which are used in projects for old WM (we use Embedded Visual C++ 3.0 or something for this) and in more modern code (VS 2010). This Embedded Visual C++ does not support STL. So if one of developers, who works in VS2010, changes a file, which is shared, and adds some function, which uses std::vector, for instance, on his side everything will be OK, but the build (which is quite long) will fail. So to see this mistake sooner, I would like to add something like #if defined(%%STL%%) #error("!!!!") #endif in all files, which are compiled with old toolset. In this case the developer could see compile time error even in VS2010. But I could not find what I can put instead %%STL%% there. Any ideas? Or maybe someone knows a better way how I can do this?
Based on a comment to the question, you could go through each of the header files that aren't supported and see what symbols they define for their include guard. Then check for those symbols being defined. E.G. The Microsoft C++ header <algorithm> defines _ALGORITHM_ so you can check for that: #ifdef _ALGORITHM_ #error("<algorithm> included") #endif A bunch of these could be collected up and put into a single header file that you could include in each shared source file, at the end.
There is quite a nice solution (at least I do not see pitfalls) %%STL%% should be _STD_BEGIN this macro is used for "namespace std {" in VS stl implementation
MPLab C18 v3.41 Header Files
I'm a newbie so be easy. I'm "trying" to build a LCD test program which was given to me by an instructor that uses the XLCD.h and Delays.h headers. Problem is that the headers don't seem to be linked during the build process as the compiler keeps tossing me an error about a function not being defined. MPLINK 4.42, Linker Device Database Version 1.7 Copyright (c) 1998-2011 Microchip Technology Inc. Error - could not find definition of symbol 'SetDDRamAddr' in file './LCD_Main.o'. Errors : 1 I used the Project Wizard and selected my chip...added the .lnk file for my chip, added the .h files for xlcd and delays, added the p18cxxx.h file. The test code is tried and true. I've done the #include at the top and I've even put the file in the same directory and then used #include "xlcd.h" but nothing seems to work for me. Yes, I've double tripple checked the syntax for errors and eventually just copied and pasted from the header file to the main.c so it's not that. Looking at the error it seems to me that only the prototype might be being seen and not the defined function. I thought that was all done with magic in the background so I have no idea how to check for paths or even if it is happening. As the whole thing is a bit of a walkthru I figured it should be straight forward but it's not. I'm sure it must just be a simple fix but I've been working on it for hours now and I'm getting ready to drop kick the stupid protoboard and PIC across the room. Anybody have an idea what I could be doing wrong? Thanks
You need to point the linker to the proper library. Go to Project->Build Options. Select the Directories tab. On the Show Directories For combobox, select Library Search Path. Click New. Then, select the directory that has your libraries. For C18 it's likely (on Windows 7): C:\Program Files (x86)\Microchip\mplabc18\v3.41\lib You should then be able to link without problem.
How should I detect unnecessary #include files in a large C++ project?
I am working on a large C++ project in Visual Studio 2008, and there are a lot of files with unnecessary #include directives. Sometimes the #includes are just artifacts and everything will compile fine with them removed, and in other cases classes could be forward declared and the #include could be moved to the .cpp file. Are there any good tools for detecting both of these cases?
While it won't reveal unneeded include files, Visual studio has a setting /showIncludes (right click on a .cpp file, Properties->C/C++->Advanced) that will output a tree of all included files at compile time. This can help in identifying files that shouldn't need to be included. You can also take a look at the pimpl idiom to let you get away with fewer header file dependencies to make it easier to see the cruft that you can remove.
PC Lint works quite well for this, and it finds all sorts of other goofy problems for you too. It has command line options that can be used to create External Tools in Visual Studio, but I've found that the Visual Lint addin is easier to work with. Even the free version of Visual Lint helps. But give PC-Lint a shot. Configuring it so it doesn't give you too many warnings takes a bit of time, but you'll be amazed at what it turns up.
There's a new Clang-based tool, include-what-you-use, that aims to do this.
!!DISCLAIMER!! I work on a commercial static analysis tool (not PC Lint). !!DISCLAIMER!! There are several issues with a simple non parsing approach: 1) Overload Sets: It's possible that an overloaded function has declarations that come from different files. It might be that removing one header file results in a different overload being chosen rather than a compile error! The result will be a silent change in semantics that may be very difficult to track down afterwards. 2) Template specializations: Similar to the overload example, if you have partial or explicit specializations for a template you want them all to be visible when the template is used. It might be that specializations for the primary template are in different header files. Removing the header with the specialization will not cause a compile error, but may result in undefined behaviour if that specialization would have been selected. (See: Visibility of template specialization of C++ function) As pointed out by 'msalters', performing a full analysis of the code also allows for analysis of class usage. By checking how a class is used though a specific path of files, it is possible that the definition of the class (and therefore all of its dependnecies) can be removed completely or at least moved to a level closer to the main source in the include tree.
I don't know of any such tools, and I have thought about writing one in the past, but it turns out that this is a difficult problem to solve. Say your source file includes a.h and b.h; a.h contains #define USE_FEATURE_X and b.h uses #ifdef USE_FEATURE_X. If #include "a.h" is commented out, your file may still compile, but may not do what you expect. Detecting this programatically is non-trivial. Whatever tool does this would need to know your build environment as well. If a.h looks like: #if defined( WINNT ) #define USE_FEATURE_X #endif Then USE_FEATURE_X is only defined if WINNT is defined, so the tool would need to know what directives are generated by the compiler itself as well as which ones are specified in the compile command rather than in a header file.
Like Timmermans, I'm not familiar with any tools for this. But I have known programmers who wrote a Perl (or Python) script to try commenting out each include line one at a time and then compile each file. It appears that now Eric Raymond has a tool for this. Google's cpplint.py has an "include what you use" rule (among many others), but as far as I can tell, no "include only what you use." Even so, it can be useful.
If you're interested in this topic in general, you might want to check out Lakos' Large Scale C++ Software Design. It's a bit dated, but goes into lots of "physical design" issues like finding the absolute minimum of headers that need to be included. I haven't really seen this sort of thing discussed anywhere else.
Give Include Manager a try. It integrates easily in Visual Studio and visualizes your include paths which helps you to find unnecessary stuff. Internally it uses Graphviz but there are many more cool features. And although it is a commercial product it has a very low price.
You can build an include graph using C/C++ Include File Dependencies Watcher, and find unneeded includes visually.
If your header files generally start with #ifndef __SOMEHEADER_H__ #define __SOMEHEADER_H__ // header contents #endif (as opposed to using #pragma once) you could change that to: #ifndef __SOMEHEADER_H__ #define __SOMEHEADER_H__ // header contents #else #pragma message("Someheader.h superfluously included") #endif And since the compiler outputs the name of the cpp file being compiled, that would let you know at least which cpp file is causing the header to be brought in multiple times.
PC-Lint can indeed do this. One easy way to do this is to configure it to detect just unused include files and ignore all other issues. This is pretty straightforward - to enable just message 766 ("Header file not used in module"), just include the options -w0 +e766 on the command line. The same approach can also be used with related messages such as 964 ("Header file not directly used in module") and 966 ("Indirectly included header file not used in module"). FWIW I wrote about this in more detail in a blog post last week at http://www.riverblade.co.uk/blog.php?archive=2008_09_01_archive.xml#3575027665614976318.
Adding one or both of the following #defines will exclude often unnecessary header files and may substantially improve compile times especially if the code that is not using Windows API functions. #define WIN32_LEAN_AND_MEAN #define VC_EXTRALEAN See http://support.microsoft.com/kb/166474
If you are looking to remove unnecessary #include files in order to decrease build times, your time and money might be better spent parallelizing your build process using cl.exe /MP, make -j, Xoreax IncrediBuild, distcc/icecream, etc. Of course, if you already have a parallel build process and you're still trying to speed it up, then by all means clean up your #include directives and remove those unnecessary dependencies.
Start with each include file, and ensure that each include file only includes what is necessary to compile itself. Any include files that are then missing for the C++ files, can be added to the C++ files themselves. For each include and source file, comment out each include file one at a time and see if it compiles. It is also a good idea to sort the include files alphabetically, and where this is not possible, add a comment.
If you aren't already, using a precompiled header to include everything that you're not going to change (platform headers, external SDK headers, or static already completed pieces of your project) will make a huge difference in build times. http://msdn.microsoft.com/en-us/library/szfdksca(VS.71).aspx Also, although it may be too late for your project, organizing your project into sections and not lumping all local headers to one big main header is a good practice, although it takes a little extra work.
If you would work with Eclipse CDT you could try out http://includator.com to optimize your include structure. However, Includator might not know enough about VC++'s predefined includes and setting up CDT to use VC++ with correct includes is not built into CDT yet.
The latest Jetbrains IDE, CLion, automatically shows (in gray) the includes that are not used in the current file. It is also possible to have the list of all the unused includes (and also functions, methods, etc...) from the IDE.
Some of the existing answers state that it's hard. That's indeed true, because you need a full compiler to detect the cases in which a forward declaration would be appropriate. You cant parse C++ without knowing what the symbols mean; the grammar is simply too ambiguous for that. You must know whether a certain name names a class (could be forward-declared) or a variable (can't). Also, you need to be namespace-aware.
Maybe a little late, but I once found a WebKit perl script that did just what you wanted. It'll need some adapting I believe (I'm not well versed in perl), but it should do the trick: http://trac.webkit.org/browser/branches/old/safari-3-2-branch/WebKitTools/Scripts/find-extra-includes (this is an old branch because trunk doesn't have the file anymore)
If there's a particular header that you think isn't needed anymore (say string.h), you can comment out that include then put this below all the includes: #ifdef _STRING_H_ # error string.h is included indirectly #endif Of course your interface headers might use a different #define convention to record their inclusion in CPP memory. Or no convention, in which case this approach won't work. Then rebuild. There are three possibilities: It builds ok. string.h wasn't compile-critical, and the include for it can be removed. The #error trips. string.g was included indirectly somehow You still don't know if string.h is required. If it is required, you should directly #include it (see below). You get some other compilation error. string.h was needed and isn't being included indirectly, so the include was correct to begin with. Note that depending on indirect inclusion when your .h or .c directly uses another .h is almost certainly a bug: you are in effect promising that your code will only require that header as long as some other header you're using requires it, which probably isn't what you meant. The caveats mentioned in other answers about headers that modify behavior rather that declaring things which cause build failures apply here as well.