| Symbol could not be resolved errors [message #1137506] |
Mon, 14 October 2013 10:45  |
Eclipse User |
|
|
|
I recently installed Eclipse Kepler for C\C++ in CentOS 6.4 running in VMware Player 6.0.
After getting all of the above installed I ran yum groupinstall "Development Tools" in my CentOS Terminal. I checked for the C++ headers after this and they all were found in \usr\include\C++\4.4.4.
The first thing I did to try and get familiar with the new environment was to create a new Hello World project. Before I did this I configured a preferred toolchain by performing the following: Window -> Preferences -> C/C++ -> New C/C++ Project Wizard and setting the preferred toolchain to Linux GCC for each project type.
Then I created a new C++ project and noted that the toolchain was the Linux GCC toolchain.
As soon as the project was created I received three error in the Problems tab: Symbol 'cout' could not be resolved, Symbol 'endl' could not be resolved, Symbol 'std' could not be resolved. Oddly enough, even with these errors the project builds and executes (output displayed in Console tab)!!!
I suspected the problem might be with the include paths for the project so I did the following to see if it would resolve the errors: Project -> Preferences -> C/C++ General -> Paths and Symbols and added \usr\include and \usr\include\C++\4.4.4 to the ath list. This does not resolve the error.
Also my #include line for the iostream header is flagged with the message (warning?) unresolved inclusion.
Can anyone tell me what is going on? How do I configure a project so that include files, both the C++ and my own user developed headers, can be found by Eclipse?
Thanks,
Mike
|
|
|
| Re: Symbol could not be resolved errors [message #1137559 is a reply to message #1137506] |
Mon, 14 October 2013 11:27  |
| Eclipse User |
|
|
|
Well after looking at similar post for this error on the forum I found a solution (or at least a workaround) for this problem.
I found a post that talked about the errors coming from the static code checker. So I started poking around the preferences to see if there was a way to set the location of the include paths for the static checker. I did not find any (but I'll keep looking) but I did find a way to turn of the error, permanently! In Window -> Preferences -> C\C++ -> Code Analysis just uncheck all the error checking!
Now I know that static checking is a "somewhat" nice feature. But when the complier is going to do this anyway we must ask ourselves is it really needed? Is it worthwhile giving up machine cycles for something that is going to be checked again anyway? Not only do unnecessary feature bloat our code, when we add a feature that does not work, like appears to be the case here, what service do we provide to our users?
While I was looking at the forum for similar post for this error, I noticed many posts where developers were frustrated with Eclipse. I have used it for years and it can be a love\hate relationship. When it works it's great, when it does not it's frustrating, but that is true for just about anything (including Congress!).
So my suggestion to the Eclipse contributors is don't bloat the software, especially if the feature does not work! And my suggestion to the complainers is be a little more professional in your posts. Offer suggestions or constructive opinions and leave the f---ing out of your posts. It short, grow up!
Mike
|
|
|
|
| Re: Symbol could not be resolved errors [message #1147216 is a reply to message #1140367] |
Sun, 20 October 2013 14:41 |
| Eclipse User |
|
|
|
Thank you Axel for your reply.
Can you be specific about what CODAN checks that the complier (gcc in this case) does not?
Also you mention that there is a great deal that CODAN checks that the complier does not. Can you quantify this?
Thanks,
Mike
|
|
|
Powered by
FUDForum. Page generated in 0.07908 seconds
Home