I have the following piece of code:
#include <iostream>
using namespace std;
int main()
{
vector<int> v; //Symbol vector could not be resolved
return 0;
}
The IDE complains about "vector": Symbol vector could not be resolved.
If I right click the "vector" keyword -> Source -> Add Include, nothing happens.
If I manually add #include <vector>, then everything is just fine, the file is indexed and I can use its member functions.
However, I expect the IDE to generate these include files for me, instead of manually adding them. How to setup eclipse to work like this?
I am using Ubuntu 16.04 and Eclipse CDT Neon.
This will only work if another file in your project already includes <vector>.
The way Add Include works is it searches the project's index for the name it's invoked on. If it finds a binding (function, type, etc.) corresponding to that name in the index, it sees what file declares that binding, and then includes that file for you.
For this to work, the binding corresponding to the name must be in the index already. For bindings declared in files external to your project (such as standard library headers), that will only be the case if the external file is already included by some file in your project.
#HighCommander4 - I noticed, through practice, the indexer behaves like in your description. There must be another file which already includes vector in order to have it in the index.
Given this behavior we can do the following:
One workaround is to have a dummy cpp file including <bits/stdc++.h>. Most of the stl headers are there. The header is available for GCC. For MSVC we can simply copy the content of into this dummy cpp file.
Another workaround is to add a linked folder to the location of the stl, in my case this is /usr/include/c++/5. In this case the whole stl library gets indexed from the very beginning.
Related
There is information on the web as well as here on the topic related to the using external file resources in CDT Eclipse: C/C++ and H files located somewhere else in the files system. All the described methods run along two methods:
creation within the project space the virtual linked files which point to
the locations of the actual files without copying them
adding the location of the external referenced resource in the
Project->Properties->C/C++ general->Paths and Symbols and related
Project->Properties-> C/C++ Build (link folders and includes)
I am not sure if the 1st method is always enough without adding the 2nd, but seems the 2nd builds well without the 1st.
My question is about a comparison of the two. Are those methods intended to be used similarly or each one is preferred in some cases?
Is each method self sufficient without applying the other?
This forum thread
https://www.eclipse.org/forums/index.php/t/1087314/ suggests that for the include files the 1st method might not even be sufficient as the Build Settings should still be updated (2nd method) to include the linked H files...then may be the 1st method is irrelevant?
You would typically use the first method if you want to edit the externally-located files as part of your work on the project, and the second method if they're just dependencies that you use without modifying.
On a technical level, the difference is that with the first method the files will be part of the project model, and so will e.g. show up as candidates in Open Resource, while with the second method they wouldn't. Another difference is that with the first method, the files are indexed independently, while with the second method the files are only indexed by virtue of being included by files in your project (so e.g. .cpp files in those directories typically wouldn't be indexed with the second method at all).
Update: answers to questions from the comment
Is the 1st method sufficient enough in all cases without updating Paths and Symbols Property ?
No, if there are header files located in the linked directory that are included by files in your project using include paths that are not relative to the current directory (so not just #include "foo.h" in the same directory, #include "../foo.h" in a child directory, etc., but #include <bar/foo.h> in some other directory), you still want to specify those include paths in Paths and Symbols.
CDT's indexer does have an "Allow heuristic resolution of includes" option (specified in Preferences -> C/C++ -> Indexer) that may allow you to avoid adding the paths to Paths and Symbols, but note that (1) this affects the indexer only, not the build (which may be fine if you're using your own makefiles for the build), and (2) as it's heuristic, it's not perfect, e.g. if you have headers with the same name in different directories it can get confused. For best accurracy, I recommend unchecking "Allow heuristic resolution of includes", and always specifying include paths explicitly.
Also can the 2nd method be sufficient in itself if referenced files to be used AS IS without modification?
I don't see why not.
I'm working on a school project right now, and every time I have in the past, I always make a new Project in IntelliJ IDEA. However, this time she gave us some .class files that have methods in them that we can't see (she described what they do so we know how to use them) but need to use, so they have to be in the same folder, obviously.
SIDENOTE: I'm also new to using Macs, which is what I'm on at the moment.
Anyways, I put the .class files in my src folder that I found in the Project8 folder. I just made an array of the Book objects, which was one of the .class files I moved, and now I need to use a method from the other .class file, named BookInventory.class. I put that file in the src folder just like the other, but it won't let me use the only method in that class, which is LoadBooks.
Here is the LoadBooks signature:
public static void LoadBooks(Book[] b)
And here's the description of it that she gave to us:
"For each element in the array, accepts user input for the book, creates the Book object, and stores the object into the array."
So, when I made the array of Book objects, IDEA made an import statement up top all by itself, I didn't type it:
import java.awt.print.Book;
So why does IDEA recognize the Book.class file and allow me to use it in this .java file for my project, but it doesn't seem to notice the BookInventory.class file?
Any help appreciated, thanks ahead of time.
What is happening is when you first typed the line with LoadBooks(Book[] b), IntelliJ could not "see" your class files (you have subsequently loaded them in "class files" and added that as a project library, I presume).
IntelliJ however searched for and found a Book class in the internal java libraries, java.awt.print.Book. Note that this is a different class to the one your teacher gave you, which might have been e.g. edu.myschool.homework.Book.
Firstly, try to delete the line including the import statement, or manually change it to the correct package (your teacher can inform you what it is).
If the same import comes back automatically, you can go into Settings -> Editor -> General -> Auto Import and untick Add unambiguous imports on the fly - this will cause intellij to prompt you before adding imports.
Also, I would ask your teacher to give you the class files in a jar file, since that's the usual approach.
Good luck.
This is probably a totally noob question but I have missing links in my mind when thinking about linking libraries in iOS. I usually just add a new library that's been cross compiled and set the build and linker paths without really know what I'm doing. I'm hoping someone can help me fill in some gaps.
Let's take the OpenCV library for instance. I have this totally working btw because of a really well written tutorial( http://niw.at/articles/2009/03/14/using-opencv-on-iphone/en ), but I'm just wanting to know what is exactly going on.
What I'm thinking is happening is that when I build OpenCV for iOS is that your creating object code that gets placed in the .a files. This object code is just the implementation files( .m ) compiled. One reason you would want to do this is to make it hard to see the source code and so that you don't have to compile that source code every time.
The .h files won't be put in the library ( .a ). You include the .h in your source files and these header files communicate with the object code library ( .a ) in some way.
You also have to include the header files for your library in the Build Path and the Library itself in the Linker Path.
So, is the way I view linking libraries correct? If , not can someone correct me on this ?
Basically, you are correct.
Compiling the source code of a library produces one object file for each of the source files (in more than one, if compiled multiply times against different architectures). Then all the object files are archived (or packaged) into one .a file (or .lib on Windows). The code is not yet linked at this stage.
The .h files provide an interface for the functionality exposed by the library. They contain constants, function prototypes, possibly global declarations (e.g. extern int bad_global;), etc. -- basically, everything that is required to compile the code which is using the library.
.h files do not 'communicate' with object code in any way. They simply provide clues for the compiler. Consider this header file:
// library.h
extern int bad_global;
int public_func(int, const void*);
By including this file in your own code, you're simply telling the compiler to copy and paste these declarations into your source file. You could have written declarations for OpenCV library and not use the headers provided with it. In other words, you're asking the compiler to not issue errors about undefined symbols, saying "I have those symbols elsewhere, ok? Here are their declarations, now leave me alone!".
The header files need to be included in the search path in order for compiler to find them. You could simply include them via the full path, e.g. #include "path/to/file.h", or supply an -I option for your compiler, telling him where to look for additional headers, and use #include <file.h> instead.
When your code is compiled, the declarations in header files serve as an indication that symbols your code is using are defined somewhere. Note the difference between the words declaration and definition. Header files contain only declarations most of the time.
Now, when your code is compiled, it must be linked in order to produce the final executable. This is where the actual object code stored in the library comes into play. The linker will look at each symbol, function call, etc. in your object code and then try to find the corresponding definition for each such symbol. If it doesn't find one in the object code of your program, it will look the standard library and any other library you've provided it with.
Thus, it is important to understand that compilation and linkage are two separate stages. You could write any function prototypes at all and use them in your code, it will compile cleanly. However, when it comes to the linking stage, you have to provide implementation for symbols used in your code, or you won't get your executable.
Hope that makes sense!
The .a is the compiled version of the code.
The header files provided with a library are its public interface. They show what classes, methods, properties are available. They do not "communicate" with the binary code.
The compiler needs the headers to know that a symbol (a method name for example) is defined somewhere else. They are associated with the right "piece of code" in the library binary later during the "link" step.
I'm trying to convert a program and its plugin from custom Makefiles to CMake, with minimal changes to the code.
Both the plugin and the app share some code; #ifdef ... #else ... #endif blocks are used where there are differences, and I'm certain the code is compiled with the correct defines. The shared code includes a class called ToolImage. When the code is compiled for the app, the ToolImage constructor uses a different resource path than when it is compiled for the plugin.
#ifdef THE_APP
ToolImage::ToolImage(const wxString& name, bool full_path_given):wxImage(full_path_given?name:
(wxGetApp().GetResFolder() + _T("/bitmaps/") + name + _T(".png")), wxBITMAP_TYPE_PNG)
#else
ToolImage::ToolImage(const wxString& name, bool full_path_given):wxImage(full_path_given?name:
(theApp.GetResFolder() + _T("/bitmaps/") + name + _T(".png")), wxBITMAP_TYPE_PNG)
#endif
{
...
}
When the program and its plugin have been compiled with the custom Makefiles, everything works as expected. When both have been compiled with CMake, using a series of CMakeLists.txt files I created, there is an issue: the plugin isn't able to load the bitmaps for its toolbar.
I tracked the problem to the ToolImage class. The line number given by gdb tells me that the plugin is using the wrong constructor. strace tells me the same thing (the plugin is looking for its bitmaps in the app's resource dir rather than in the plugin's resource dir). To ensure that I didn't have the defines screwed up, I put a #error in ToolImage.cpp, inside the part of the #ifdef that should only be compiled for the app - and the plugin still compiled without error. This tells me that the plugin is compiling with the correct code. Since it is using the wrong path, I think it is using the class and constructor compiled into the program instead of its own.
How do I ensure that the plugin uses its own ToolImage class instead of the one in the app?! I don't own the project and don't want to make massive changes merely to support building with a different build system.
Using the precompiler to create two versions of a class seems like a poor choice to me. If I must make changes to the code, do you have suggestions for a workaround?
For the sake of experiment, I'd add -fvisibility=hidden when building theapp, to all or maybe to some specific sources. This should hide application's ToolImage from the plugin.
It is not a universal method, as in many cases plugins do use different symbols from the main executable.
I fixed this by adding the linker flag -Wl,-Bsymbolic-functions in the CMakeLists.txt:
set_target_properties( heekscnc PROPERTIES LINK_FLAGS -Wl,-Bsymbolic-functions )
Is it possible (and how) to add the namespace in the name of the automatic generated include guards in Eclipse CDT, when creating a new class using the .hpp/.cpp templates?
For me Eclipse generates a new class with a namespace nicely, but the include guards do not contain the namespace, so if the same header file exists twice in two different directories, only one can be included.
In my case the name of the namespace, the Eclipse project name and the name of the source directory are all the same, so these could be alternatives as prefix for the include guard.
So in the Preferences dialog under C/C++ -> Code Style -> Code Templates you can modify the template to be closer to what you need, for example if you need the namespace in the guard, you can do something like.
${filecomment}
#ifndef ${namespace_name}_${include_guard_symbol}
#define ${namespace_name}_${include_guard_symbol}
${includes}
${namespace_begin}
${declarations}
${namespace_end}
#endif /* ${namespace_name}_${include_guard_symbol} */`
There's a hidden preference you can set to get at least the file's path or a uuid in there instead of just CLASSNAME_H_. See my full answer here.