Importing a CMake project into Qt Creator is easier than it is with Eclipse (which is described here). The problem is that you cannot do this properly by using the Import option. Counter-intuitively, you need to Open Project to import a CMake project and make a Qt Creator project from it. After this operation, the project will be available in Qt Creator always, with auto-complete (thanks to indexing) and building (thanks to make).
To do this:
Do Open file or project and open the CMakeLists.txt file.
Choose the Build directory properly. Qt Creator will create a .cbp file here with the name of the CMake project.
Qt Creator will ask you to run cmake once, so that it can learn the include, library and build directories.
You are now in the project Qt Creator has created for you. It will index the files perfectly, so you get excellent auto-complete (better than Eclipse).
Click the Projects button in left column and you will be able to set the command options to build and the environment variables for build.
In Eclipse, I am able to build and run C++ code that calls OpenGL functions. However, most of the OpenGL calls are marked as could not be resolved by the Indexer in Eclipse.
Almost all of the modern OpenGL functions are defined behind the GL_GLEXT_PROTOTYPES symbol in header files such as gl.h and glext.h. We need to define this symbol for the Indexer.
Go to project Properties -> C/C++ General -> Paths and Symbols. Under the Symbols tab, add a new symbol with the Name as GL_GLEXT_PROTOTYPES. No value needs to be provided. Rebuild the index for the project and the unresolved indications for OpenGL functions should be gone!
Eclipse CDT understands the C++ code in a window by running it through an indexer. This indexer is nothing but an invocation of the GCC C++ compiler with certain compilation options. Sometimes, you might want to change the compiler options used by this indexer.
For example, I recently found that C++11 containers and classes (like future) were not resolved by the indexer and were underlined with red squiggles. This is because the compiler options used by the indexer does not have -std=c++11.
To change the compiler options of the indexer:
Open Preferences and go to C/C++ -> Build -> Settings.
Click the Discovery tab and choose CDT GCC Built-in Compiler Settings.
Modify the command string shown below it as you wish. For example, here I added -std=c++11.
Eclipse CDT will automatically re-index your C++ files after this is saved. However, I found that this did not remove the unresolved items.
I manually re-indexed by right-clicking the project and choosing Index -> Rebuild. This worked!
When working with C++ code in Eclipse, you might see a Unresolved inclusion warning for some include header lines. This is indicated with a question-mark and an underline squiggle. On hovering the mouse over it, a tooltip is shown with the Unresolved inclusion message.
This is caused when the Eclipse indexer cannot find the header file you have included. This commonly happens when you have installed the library of that header file in a non-standard location.
Open the project Properties and go to C/C++ General -> Paths and Symbols.
In the Includes tab, go to the GNU C++, choose Add and add the path to the directory that contains the above header file.
After re-indexing the code of your project, this warning should be gone.
The biggest problem of C++ code is bugs. Bugs can slip through even when compiling code with all warnings turned on. A useful tool in the arsenal of a C++ programmer is CPPCheck, a static analysis tool. You are in luck if you are using Eclipse CDT because the CPPChEclipse plugin makes using CPPCheck with your C++ project very easy.
Go to Window -> Preferences -> C/C++ -> CPPChEclipse. First, set the path of CPPCheck to /usr/bin/cppcheck. In the Problems subsection, choose the types of problems you want to be reported about (warnings, errors, style problems). In the Settings subsection, choose the C and C++ standard versions you want to be applied. You can also indicate the CPPCheck use the include paths used by your project (this is very useful).
To run CPPCheck on a project, right-click on its name in the Project Explorer and choose CPPCheck -> Run CPPCheck. The default keyboard shortcut for this is Shift + Ctrl + C. After CPPCheck runs, you can view the problems it has reported in the Problems view at the bottom of Eclipse.
The include graph of a large C++ project can be really gnarly. Sometimes, you end up with compile errors due to circular inclusion of types or headers and cannot figure out the origin of the error. Other times, you might want to know the path of header files through which a certain type is available in a source file. To view these details, I generate a header include graph using Doxygen.
However, if you are using Eclipse CDT you have something that is easier and more convenient: its Include Browser! 🙂
To open it: Go to Window -> Show View -> Include Browser. It will typically be displayed at the bottom of Eclipse.
To view the include graph of a source or header file: Go to the Project Explorer, find the file and drag its name into the Include Browser window.
By default, the include graph of the includes of the file are displayed.
You can also view which other files include the current file.
If the include graph is too cluttered, you can disable display of system includes. These are typically standard C++ header files.
You can also disable display of includes in inactive code.
CPPLint is a tool created by Google that can be used to check a C++ source or header file. It is a single file Python script. It would be nice to apply CPPLint on a C++ file in Eclipse CDT whenever it is saved. This is possible by using the CPPStyle plugin for Eclipse. It runs cpplint.py on a saved C++ file and displays the reported errors conveniently in a Problems view, as shown in screenshot above.
Eclipse is developed as a modularized system with a central core platform and additional features and plugins that provide functionality required for a certain language (like Java or C++). These packaged versions of Eclipse that are put together for different languages is what is provided on its download page.
You may feel that the Eclipse packages available for Java or C++ (CDT) are extremely bloated with hundreds of features and plugins that you may never use. For example, Eclipse CDT includes hundreds of MyLyn features and cross-compiler support, none of which I may require right now. The beauty of Eclipse is that everything is a plugin, so you can actually build yourself a lean Eclipse that only includes what you want. This way you can build a minimal Eclipse that has only the features you want.
Step 1: Get the platform runtime binary
The core of Eclipse is provided for download as Eclipse Platform Runtime Binary. To get it, go to this page and click on the build number you want. It opens a new page, where you scroll down to the section named Platform Runtime Binary and download the package matching your system.
Unzip the zip file you downloaded and run the eclipse binary file. The IDE opens and it works.
Step 2: Add the plugins
Now add the plugins you want from Help -> Install New Software. For plugins provided by Eclipse, choose Luna from the dropdown. For external plugins, add their URL.
For creating a Eclipse C++ IDE of my own, I installed these plugins:
Luna -> Programming Languages -> C/C++ Development Tools
I compiled C++ code using the g++ compiler. The -g option was specified so that the executable had debugging information. I could run the program using gdb and place breakpoints and look at the source code. However, when I tried to print the value of a variable in gdb, it threw this strange error:
(gdb) print i
No symbol "i" in current context
I tried using Eclipse CDT to compile and debug the same C++ code. Again, I got a similar result. I could run in Debug mode and the program could stop at a breakpoint. However, the Variables window did not show any of the local variables. Hovering the mouse cursor over any local variable did not show its current value!
The culprit turned out to be a mismatch between the compiler and debugger! I had recently switched to GCC 4.8, a newer version. However, I was still using the old version of GDB. In v4.8, GCC produces debugging information in the DWARF4 format, as explained in its release notes. However, this older version of GDB could only understand DWARF3 or versions older than that. It was failing silently when local variables were requested.
The solution was simple: request GCC to produce debugging information in the older format by specifying -gdwarf-3. Once I did this, GDB could print local variables and they appeared in Eclipse CDT too.