I m trying to understand how an IDE (I'm using Visual Studio) knows where to find the implementation for a header file's declarations.
Let's say that I have 2 cpp files and 1 header file:
main.cpp, contains main() function and includes person.h
person.h, contains some class declarations that are implemented in person.cpp
person.cpp, contains the implementation of the person.h declarations, and also defines person.h
So my understanding is that main.cpp and person.cpp know where to find the function declarations, but person.h has to search in some .cpp file for these implementations.
Now, how does Visual Studio keeps track of this? Each time a new header file is created, does VS needs to parse every .cpp file in the project to find where the declarations are implemented? Header files don't have any declaration of which .cpp files to search for, yet it finds them! Is Visual Studio scanning each .cpp file in the project?
So, what happens in a large project, with hundreds, or thousands of .cpp files? This does not appear to be very efficient, so I figure VS must do it in a different way. Do you know how?
PS: Not about compiler/linker process, but rather how VS IDE works (even before compiling or link the final exe)
Intellisense is the name of the Visual Studio feature which links definitions to declarations; which lists completions when typing identifiers; and which draws red squiggly lines under errors.
Intellisense works by continually scanning every source file in a solution, including new definitions as you type them. Records about all of the constructs in the source code are stored in a database, which is located on disk in a "solution_name.VC.db" file. When a new definition or declaration is added, whether to a header or source file, Intellisense doesn't have to take very long to look up any related items in the database.
If you delete the .VC.db file, and then open the solution, it will take a noticeably long time for Intellisense to rescan everything before it starts working very well. The IDE will also tell you that it is "parsing" files in the status bar.
I am working on a Iphone Application. I need to use C++ code inside MainViewController class. For that I renamed the MainViewController.m to MainViewController.mm in order to accept C++ code.
However after doing that it looks like it lost the link with the MainViewController.h file. I can no longer synthesize properties declared in the .h file and can no longer create action in the header file. It can't find the .mm file. and if I try to "Jump to definition" it says Symbol not found
How can I fix that. Thank you for any help
Close and reopen the Xcode project
if that fails, Build and remove any errors which may have been introduced as a result of changing the type to compile as.
if that fails, Clean All and rebuild.
if that fails, got to the Organizer, choose "Projects" > *YOUR_PROJECT* and Delete its Derived Data.
So I’ve got a HEADER(.h) and a SOURCE(.cpp) file in a Managed C++ VS2010 solution.
My solution builds successfully even though I added garbage to the header.
public:
someConstructor(); // assume the syntax is good here
asdf // garbage
Why I did this
My original problem was that I couldn't update my CPP file to add a new constructor. When I added a new constructor to my CPP file, my solution failed to build due to a non-existent overridden member function, i.e. my new constructor. I added garbage to the HEADER file to make sure that VS2010 was actually reading my HEADER file. Obviously it was not.
How can I make sure that VS2010 looks at my HEADER file? It seems to be looking at another HEADER file...
Thanks
If you select the file(s) in question and open up the properties window (View->Properties Window) you can see if your project is looking at the correct file or not. Additionally, if the file is not being included in the build (even though it's in the solution), you can set Include in Project to true.
Note that I'm assuming you're using MSBuild. If you're using some other build system, there may be a different procedure for ensuring the build is using the correct header file.
So,
I've got this code I'm trying to update. It was written for visual studio 6, and I'm trying to get it to compile in visual studio 2010.
In stdafx.h, it includes afx.h and afxwin.h and a few other things necessary for the program to work. Notably, there's usage of CString in other header files.
At the top of the includes in stdafx.h, I added in a #pragma message, to verify that it was being compiled first. There's one at the top of the header file which throws the error, as well. I can see from the compiler output that stdafx.h was being compiled first, so that's good.
However, there was the error. (CString wasn't being recognized as a type.) So, I decided to make sure that it got through all of the includes. So, I put another #pragma message after #include and that message is not printed.
Does that mean is not actually being included?
Your explanation is a little hard to follow, but I think you're running into the differences between normal compilation and pre-compiled headers.
With pre-compiled headers, the compiler processes the first file normally (the new project wizard sets up stdafx.cpp for this). After processing the include file (typically stdafx.h) set in project options for pre-compilation control, the compiler saves its state to a .pch file.
For every other file, the compiler skims over the file without any processing, just looking for the include file. Then it reads the .pch file, loads the saved state, and continues parsing and compiling normally.
One consequence of this design is that any lines above #include "stdafx.h" in stdafx.cpp become part of the state and are seen by all other files. And lines above #include "stdafx.h" in other files are simply ignored.
Passing my comment to an answer.
CString in VS 6 times was a class and it changed afterwards to be a template. Maybe it has something to due with that?
The problem had to do with using
typedef with CString. Post VS 6,
that's not possible. I just changed
references by hand, and it compiles
now.
The problem had to do with using typedef with CString. Post VS 6, that's not possible. I just changed references by hand, and it compiles now.
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.