When I build my C+ project in Visual Studio 2010 using Boost 1.54 and toolset v90, I get a bunch of IntelliSense errors (see image below). My project still builds fine and runs as I'd expect. These errors aren't preventing me from working on my code, but they are really annoying. How do I either fix them or hide them?
I found this post that mentions one of the errors. It suggests that I include <boost/cstdint.hpp>. I tried that but nothing changed. I checked greg_calendar.hpp where the error is happening and it already includes <boost/cstdint.hpp>.
I had the same issue, don't know if this helps but my boost directory resides on D drive (D:/boost to be exact) and my project files also reside on D. My reference to it in the Visual Studio Include Directories was '\boost'. This compiled fine as it was on the same drive but intellisense was still saying I had errors so I changed it to be more explicit (D:\boost) and that fixed it up. Hope this helps anyone in the future.
I'm having this very strange problem when I try to run my program on code blocks using a g++ compiler. I have installed boost AND used it up until perhaps a week ago, I never had any problems. Today, I returned to a project I was working on and suddenly I get the following error message when I try to run it
The program can't start because libboost_thread-mgw47-mt-1_53.dll is missing from your computer. Try reinstalling the program to fix this problem.
Now I've used boost thread before in this program, so I have no idea why I'm getting this. What's also strange is that boost threads work in other projects I have.
How do I go about trying to solve this? Everything seems to be in place, path variables set, compiler, linker options set, etc... Nothing, that I'm awawre of, has been changed since the last time I ran this program successfully. I did update Visual Studio today, but I don't think that should have any effect. I'm not really sure what other information I can give since I have no idea why this is happening. The .dll file does certainly exist, I've tried moving it into the working directory but still get the same error.
Anyone have any suggestions on how I can go about solving this?
Your compiler in that project is dynamicly linking the boost thread library,
Probably some misconfigured settings in linker options or your code uses dllimport instead of 'normal' functions which are resolved at compile-time (dllimport resolves functions at runtime - it can't find them in the required library so you get an error).
Your other projects work because they staticly link the boost thread library (provide the corret boost preprocessor definisions for static linking/compiling and include the corresponding cpp/lib files for the thread library) so it's included in the program.
So I figured it out. (note again, I'm using code blocks)
I had everything set up in the global compiler and linker settings (which I thought would enough). I had everything set up in the individual projects compiler settings, but the project that was working also had some extra stuff in the linker settings. So I had everything set, EXCEPT the settings in the Project -> Build Options -> Search Directories -> Linker part, with the project name selected, not debug/release. I added in...
$(#boost.lib)
............\boost_1_53_0\stage\lib
and now it's fine.
Sort of surprised that the global compiler settings doesn't cover the individual project settings, but there you go.
The dll compiles fine as unmanaged code, however when I add /clr and change to Use MFC in a Shared DLL in the project properties, mfCFtpConnection::GetCurrentDirectory gives me LNK2028 and LNK2019 errors. Which are unresolved token and unresolved eternal symbol errors.
I have #include and linked wininet.lib. So I am puzzled.
I read a post online where the user had this issue and it was related to mfc100.lib renaming CFtpConnection::GetCurrentDirectory to CFtpConnection::GetCurrentDirectoryA. There was no work around and a microsoft rep said it would be fixed in future versions of mfc100.lib. I do not know if that is the problem.
Here is the link to the post.
Link to online Post
Any ideas it is driving me crazy.
Also I tried CFtpConnection::GetCurrentDirectoryAsURL and the code compiled fine.
I think this error stems from the fact that there are some #defines used to sneak around CLR restrictions for MFC dlls.
If you're using VS2010, you can hover over the method name and you will see the #define statement that is renaming your method in the generated .obj file. Since it's been renamed, the other modules in your code won't be able to link to it.
I'm having a problem with eclipse C++ juno. My project compiles and runs from command line but eclipse (juno) keeps saying there are thousands of errors. For example there's a function SetRun in my code, and eclipse mentions this error: "called Invalid arguments 'Candidates are: void SetRun(?)'", whereas SetRun is of type static void SetRun (uint32_t run);
I have quite a lot of similar errors like that, where eclipse doesn't seem to understand the type of the function and puts a '?' instead.
I also have many errors like this: "symbol '*' could not be resolved."
I also have many includes that can't be resolved, although they are resolved just fine by the compiler.
I think this is all part of the same issue.
I should also note that I had this working with eclipse previously, but now everytime I open eclipse it appears that way.
If I build the project from eclipse, it build successfully.
I tried updating the index but it didn't change a thing.
What can I do to make eclipse stop telling me about these errors?
edit:
here is an example of a include that is not resolved:
#include "ns3/core-module.h"
I had the same problem in my project. Try the following:
Right click on the project name
Then Index
Then Freshen All Files and wait.
This worked for me.
You have to manually add include and symbols paths in your project preferences. Follow this instructions. You can find a lot more information about it just goggling set up include paths eclipse.
It is normal that even though you Eclipse editor cannot resolve the path, your compiler can, because they use independent settings.
EDIT: Looks like in your case you are interested in using ns-3 in Eclipse, then you should follow this instructions.
In the past, i had too many issues with C++ projects under Eclipse that I eventually ended up switching to another IDE. Unless you really have to work under Eclipse, i suggest you switch to another one.
I have updated my Ubuntu box to 11.10 and then Eclipse also have been updated to 3.7.0 Indigo with CDT 8.0.1
Then the following problem occurs:
I have included the vector header file but the compiler said that Symbol 'vector' could not be resolved. I also defined #define int Comparable, but Eclipse also said Symbol 'Comparable' could not be resolved and so on....
Although lots of errors occur, compiling was finished successfully!
I have tried to use g++ to compile the code, it had no problem.
The problem is that there are a bunch of include directories that are missing from the indexer's perspective.
Adding the following worked for me, but may depend on your particular setup where they actually exist:
/usr/include/c++/4.6.1
/usr/include/
/usr/include/c++
/usr/include/c++/4.6
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/
They can be set in Project>Properties>C++ Include Paths
Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.
Time after time a crash of Eclipse, the VM or the computer or even just long months of development start to wear down the stability of the workspace where Eclipse stores everything.
Check the <workspace dir>\.metadata directory to get an idea of just how much Eclipse generates and stores in your workspace. Every time you add a plugin, upgrade a plugin, remove a plugin that puts and changes information in your workspace.
A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).
The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.
Eclipse help docs tell us what this command does:
if set to "true", any cached data used by the OSGi framework and
eclipse runtime will be wiped clean. This will clean the caches used
to store bundle dependency resolution and eclipse extension registry
data. Using this option will force eclipse to reinitialize these
caches.
There are three ways one can use the -clean command line argument:
Edit the eclipse.ini file located in your and add it as the first argument on the first line.
Edit the shortcut you use to start Eclipse and add it as the first argument.
Create a batch or shell script that calls the Eclipse executable with the -clean argument.
The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.
This page solved the problem to me!Hope it can help everybody else.
In the project properties, go to C/C++ Build > Tool Chain Editor, tick Display compatible toolchains only, and select Linux GCC and click Apply button.
Now if you go to C\C++ General > Paths and Symbols, you will see new list of include paths added. If you rebuild index, the error messages should go away.
The code analysis is causing this. It's not actually compiling the code but just doing some static checks for quick feedback. Unfortunately I don't know how to fix it, I just disabled it. Sorry I'm at work so I don't have CDT in front of me but I think it's something like:
Window > Preferences > C++ General > Code Analysis
Go there and un-check all the boxes to disable it.
When you create a C++ project (in my case from existing code) you have to set the 'Toolchain for Indexer Settings' to the compiler you use ('GNU Autotools Toolchains' in my case).
After this 'Path and Symbols' will show the correct path to the include files of your compiler.
The bugs will disappear.
This setting was useful only during creating the project, setting it later did not help.
In indigo 3.7.2 version (and up may be) your changes can be effect after reindexing. Eclipse ask for "reindexing". Lower versions can require a manual reindexing header tags etc.
Updated index option to active build configuration works for me,
also I removed some files from the file list of being indexed up-front,
Ok here is what worked for me:
deleted the path to the header files I created from the include path
compiled the project (obviously the compiler complains since it is missing user-defined headers)
reinserted the path to the header files I created
compiled the project again - worked perfectly
I can't explain the case :(
I am answering here because this is the closest question to my problem.
I used QT Eclipse integration with Helios (3.6.2) with no major problems. I was using mingw 4.6.2, which I had installed to c:\mingw. I wanted to upgrade to Indigo, which fixed some minor issues I was having with CDT.
However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:
function 'fprintf' could not be resolved
function 'memset' could not be resolved
even though #include was not underlined, could be opened, and included fprintf in the header. And even though the code itself compiled fine.
If I went back to Helios, the problems went away.
I tried reindexing, to no avail. I checked my include paths, and they were:
c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include
At first, I had just included the first, but not the second. But then I searched for "unresolved includes", and stdio.h was including stdarg.h, which wasn't in the main include folder of mingw, so I added the second. But still, printf was not resolved, and there were no more "unresolved includes".
I created a new C++ project with one class. I added stdio.h, the paths above, and a call to fprintf. It was underlined! Even though other things from stdio were not underlined.
Now I knew that it wasn't just a Qt problem.
I worked around on this for a while before I read the bottom post here suggesting removing the include paths and compiling. I didn't believe it would work but gave it a shot. Amazingly, even though the compile failed, the error went away!
It was then that I took another look at the include paths. They had been updated by the compile step to the following:
c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++
These were marked as "built-in" values which I assume means they weren't added by me and could get updated the next time I run a build.
So, I guess the lesson is, including every single include path under mingw, even if Eclipse doesn't find it to be an unresolved include.
The next step was to put all these paths into my Qt project. Unfortunately, after doing so, the unresolved functions were still there. It appears to be some sort of bug with the Qt C/C++ include paths which are different from the CDT C/C++ include paths.