Multiple "Could Not Be Resolved" Problems Using Eclipse with Mingw

Multiple could not be resolved problems using Eclipse with minGW

Go to Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros, etc. -> Providers -> CDT GCC built-in compiler settings, deactivate Use global provider shared between projects and add the command line argument -std=c++11.

The eclipse live code analysis does not share the same settings with the build compiler. You can also change the setting globally (not just for the project) in Window -> Preferences -> C/C++ -> Build -> Settings -> CDT GCC Built-in Compiler Settings.

Edit: You need to #include <string> to use std::to_string.

Eclipse CDT: Symbol 'cout' could not be resolved

Most likely you have some system-specific include directories missing in your settings which makes it impossible for indexer to correctly parse iostream, thus the errors. Selecting Index -> Search For Unresolved Includes in the context menu of the project will give you the list of unresolved includes which you can search in /usr/include and add containing directories to C++ Include Paths and Symbols in Project Properties.

On my system I had to add /usr/include/c++/4.6/x86_64-linux-gnu for bits/c++config.h to be resolved and a few more directories.

Don't forget to rebuild the index (Index -> Rebuild) after adding include directories.

string could not resolved error in Eclipse for C++ (Eclipse can't resolve standard library)

The problem was that I needed to have both minGW and MSYS installed and added to PATH.

The problem is now fixed.

Why is the Eclipse C++ symbol 'std' could not be resolved error fixed by saving the file?

Eclipse's CODAN tool runs as you type, unfortunately it only parses dependencies on demand, usually with a save.

Why? Eclipse's CODAN tool isn't exactly a gazelle, so having to track through all of the file's dependencies while the user is typing is probably a system killer. This may improve with time. In the meantime, save regularly.

And, to be honest, this is probably a dodge. It should only have to search dependencies when a dependency is added. But there are a lot of buts. What about when a dependency is added to a dependency? Or a new dependency is hidden in a macro (don't do this) and hard to parse without digging through the dependencies? Or exposed by adding a define that triggers conditional compilation (I prefer different implementation files and letting the linker sort it out to conditional compilation)? What about...?

Blah. If people want to write garbage code, that's their problem. A static analyzer should focus on the needs of people who aren't trying to trick it and circumvent good style. That said, I don't know the CODAN code, and I don't know how deep one would have to go to change it to catch and handle the easy cases at a tolerable real-time rate.

But at the end of the day, the only analyzer you should pay attention to is the compiler--with the warning levels turned up to 11, of course. CODAN is not perfect. It misses and misinterprets stuff, and you may find yourself hunting a bug that's not a bug in your code. If the compiler has a bug, that's a different case, but a lot less likely. Definitely take CODAN's help, but before you spend time on an odd error, make sure it really is an error by saving and building the program.

CODAN configuring stuff:

Most of CODAN's options can be found by visiting Project->Properties on the menu and navigate the Properties dialogue to C/C++ General->Code Analysis

To turn configure CODAN's run options, to turn off updating as you type for example, go one step further to C/C++ General->Code Analysis->Launching

You will also find that if you are editing included headers in another project, you will have to force an index rebuild to to catch the modifications. Select Project->C/C++ Index->Rebuild from the menu for the project doing the including.

Eclipse CDT error: Symbol 'XXX' could not be resolved

Running around without a proper toolchain configured in Eclipse was the problem. For ARM development using cross gcc, this Eclipse plugin fixed my problem and looks promising in general. It gives you Eclipse project settings for the whole toolchain and means you can ditch your makefiles.

http://gnuarmeclipse.github.io

macro passed from compile cannot be resolved in eclipse

Properties -> C/C++ Build -> Settings -> GCC C++ Compiler -> Miscellaneous

Wrong place.

Should be "C/C++ Build -> Settings -> GCC C++ Compiler -> Preprocessor"

Just verified it works.

---

Related Topics