With NetBeans (v. 6.9.1) I cannot get syntax highlighting for the Boost library, i.e. all stuff present in Boost is not recognised. However the project is built correctly.
I already set the paths in: NetBeans > Preferences > C/C++ > Code Assistance > C++ Compiler.
Here I added the /usr/local/include path.
The Boost headers are in /usr/local/include/boost, so if in my code I use something like:
#include <boost/interprocess/containers/string.hpp>
the include file should be found by the editor (as it is found by the compiler).
What am I doing wrong?
Thank you.
OS: MacOS X 10.6.4
P.S.: I got this problem after updating Boost to the latest version (1.44.0); previously it worked fine (with v. 1.41.0); I must have done something differently now, and I do not remember the details of what I did last time.
P.S.2: Now I can get to the include files right clicking on the #include directive. However syntax highlighting for Boost items does not work, yet.
I don't know if this is the same problem you are having but I find that Netbeans frequently gets confused about syntax highlighting and includes. I'm not entirely sure what triggers it but I've found that it can often be cleared up by shutting down Netbeans and deleting the cache directory ~\.netbeans\6.9\var\cache.
Related
I am trying to get Google Or-tools to work, I followed this tutorial to install it: https://developers.google.com/optimization/install/cpp/windows.
After running the tools\make test.cc, I created new C++ project, added includes of the library to C/C++ additional includes. When I try to build/run I got errors like these: https://i.imgur.com/0VuWNcg.png.
I have win7 64bit and MSVC 2019 so it is a bit different than theirs configuration but this does not seem to be connected.
The identifier errors look like this: https://i.imgur.com/B4YMqM9.png
The error in optional_boolean looks like this: https://i.imgur.com/Wr2l1Xv.png
Does anybody knows what is happening? Does their code have errors or am I doing something wrong?
(I also tried to compile directly from the source but bumped into different problems...)
You changed the includes, but did you change the libraries to link with.
Anyway, you should have a look at:
https://github.com/google/or-tools/issues/1449
I finally managed to get it working. The problem was faulty distribution of google or-tools. At least the problem was with library used by or-tools while using MSVC - it can be some sort of mutual incompatibility, I really don't know, but still they couldn't have tested it and I don't understand how that can happen and get into release).
Steps to solution were these:
Grab this version of or-tools:
https://github.com/google/or-tools/releases/tag/v6.10
Extract it where you wish to have it.
A If creating completely new project:
Grab this (thanks to #Laurent): https://github.com/philippe3263/ORTools_Visual_Studio
Reconfigure include path, lib path and in Linker->All Options remove/delete Additional Options.
B If editing existing project:
Set x64 debug profile.
add include and lib paths.
Add ortools.lib to extra libraries.
Add preprocessor directives _WINDOWS NOMINMAX USE_CBC USE_CLP USE_BOP USE_GLOP
It's possible that other settings are necessary like C/C++ -> Code generation -> Runtime library to /MD but since I already had a lot of custom settings I can't tell what is needed. (but checking the link and going through those settings can help)
Tested on Win7 64bit with VS 2019
I was bothered by the error
fatal error C1083: Cannot open include file: 'iostream.h': No such file or directory
for quite a while, I tried my best to search all the relevant cases but couldn't find a good answer for me.
My situation is, I have a simple piece of code with a couple of dependencies to build, after setting up all the include folders, I'm just experiencing this compiler error all the time. Two weird questions I cannot answer,
There is another win32 console project somebody else set up for this project, working! I'm trying to copy all of his settings (the command line options are exactly the same, all env variables are same, and I run two projects on same visual studio), but just have this 1083 error in my own project.
I was playing around with the settings, one time I changed the platform from Active(Win32) to Win32, then suddenly the compiling works, but after that time I couldn't reproduce it any more.
The thing is, I'm guessing VS in my project might go to a wrong directory
C:\Program Files\Microsoft Visual Studio 8\VC\include instead of C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include
not quite sure, and earlier I was trying to compiling using a building script and make files, same error happened because there people didn't update the correct VS directory.
Sorry I couldn't provide the source code here, and it won't be helpful either since it has a couple of levels of dependency. But I hope based on my description some one might give some idea which direction should I go or spend time on.
iostream.h is deprecated, it should be just iostream:
#include <iostream>
See <iostream> vs. <iostream.h> vs. "iostream.h"
In this version of visual studio (and also in any modern C++ IDE) standard library headers are named without any suffices (iostream instead of iostream.h, string instead of string.h, etc)
Also, C library headers are named like cxxx instead of xxx.h, for example, you should include cstdlib instead of stdlib.h
When you say that you ran your project and the other person's (working) project on the "same visual studio", do you mean the same installation or the same version? If they're not on the same installation, then even if the project settings are copied exactly, it could be that the installation settings are different and that that's what's causing the problem. This may be a long shot, but I'll do my best to explain.
I came across your question because I had a slightly similar problem. Even without dependencies, I couldn't get a simple "Hello, World" program to compile. I used iostream without ".h" as many people suggested and still got C1083. Then I realized that when I installed VS, I unchecked one of the basic features, called "Visual C++ Run-Time Libraries". So I modified the installation to include this feature. Afterwards compilation proceeded successfully and the problem was solved. Is it possible that your installation is missing something that the other person has? If you can get your project to work on this other person's installation, then that might help to pinpoint the problem. Hope this helps. Good luck!
Does a simple hello world program that uses <iostream> compile and run fine?
If so, the Visual Studio system settings are fine and there is something probably wrong in either the project settings or the source.
You can eliminate the source by checking to make sure that the code is actually using #include <iostream> as opposed to #include <iostream.h>. Once that is done, make sure your header search paths point to the right place (the same as the default values in your hello world project for a start)
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.
i have the following Problem.
I started to use the boost library version 1.40, for unit testing.
Since some other people working on the project and not all of them are using eclipse, the program has to be compilable with a makefile. So we used cmake to generate one.
The good thing is, the test is building and working perfectly fine.
But the problem is, when using eclipse (created a c++ makefile project), it complains about several syntax errors (in the sourcecode view).
Something like:
BOOST_AUTO_TEST_CASE( my_test )
{ some code }
will be detected as a syntax error by eclipse. It is really annoying having all these error messages in the IDE. Since after the first line nearly every line in the some code block is marked as having syntax errors as well.
So here is what i tried already:
I added `/usr/include/boost/` to the GNU C++ path options. (properties->C/C++ General->Path and Symbols->Path). This works normally for other external libs that are included by FindPkgConfig in the cmake file. So that the auto completion in eclipse can find the correct classes and function names.
Same way included `/usr/include/boost/test/` directly.
Adding `/usr/lib/libboost_unit_test_framework.so.1.40.0` to the Libraries list.
Adding `/usr/lib` to the Library Paths.
So anyone has a hint how to teach eclipse that the syntax of the boost Macros is correct??
Update:
I forgot:
System is Linux and Eclipse Version is 3.6.1, CDT Version is:
Version: 1.0.0.201009141542
Build id: 201009141542
I don't have a solution but maybe a hint.
I had a similar setup and it worked perfectly until...
the only relevant change I remember is that I changed the name of a test suite.
So (probably) after that, the syntax highlighting went crazy.
I tried indexing and refreshing but it didn't help.
I can't even see the macro expansion because the syntax error prevents it from popping up.
My guess is — still — some indexing issue, because it worked before and I didn't change any include paths. It compiles without problems, but it's urinating these yellow syntax error markers all over the document, which is really, really annoying.
However, it's probably not a path issue because it worked for me before.
I just did this myself using Eclipse Helios, and it does indeed work for me...
Shouldnt you add /usr/include and not /usr/include/boost, since boost is part of the include path used in your program?
For example <boost/unit_test.hpp> is simply <unit_test.hpp> if you include the boost folder aswell..
This is what I have added under GNU c++ include directories:
/usr/local/include //this is where I store the boost folder
/usr/include/c++/4.5.2 //This was needed since not even <map>, <vector> etc would resolve in eclipse.
Intellisense and autocompletion for C++ are pretty much impossible to get right in all cases. If the many macros used in Boost.Test confuse Eclipse, then perhaps you should find a cleaner unit test library. I can recommend Catch, which has a cleaner and friendlier syntax, is header-only so it's much easier to set up, and doesn't rely on macros. It is under active development by another SO user.
I had this problem as well (but on a Mac system). Once I added the boost path to GNU C++ path options, I restarted my operating system and Eclipse doesn't tag BOOST_AUTO_TEST_SUITE as an error any more.
EDIT: I have solved this problem, with Tomalak's help. It appears that I mistakenly uninstalled libstdc++6-4.4-dev_4.4.3 when I was making space to install code::blocks into, thus removing the STL headers. Code::Blocks now works perfectly fine.
Hey everyone, I'm back yet again to bug you.
I have recently installed Code::Blocks in order to follow along with a SDL tutorial, mainly to make it easier with the file creation process (i.e. not having to deal with makefiles for the time being)
I have been compiling/running the examples (so far) just fine, but I've now hit a snag.
On the tutorial for entities, the header file includes <vector> - yet code::blocks is stating it cannot find said header file. It's a .h header file, but it's recognizing it as C++ (I think, judging from the project options) - all my headers are .h, all my sources are .cpp...
I have searched Google for a solution, and many people state that this error occurs when they try to use in a .c file by mistake. This is not the case, unless Code::Blocks is recognizing my .h as a C-header.
In case you're wondering, I am running Lucid Puppy Linux 5.2 (aka LuPu), a Ubuntu derivative. (Installed Code::Blocks from the Ubuntu repositories)
In advance, thank you very much for the help.
As it turns out, it was not a Code::Blocks issue - I had mistakenly un-installed the libstdc++6-4.4-dev_4.4.3 package.
So, if any of you all get this same problem make sure the libstdc++ development files are installed! LOL