When I'm editing a source file and use content assist, then I don't want it to suggest variables/functions/etc. from other source files which I didn't include. It should only suggest things from the current file and from included headers. How can I make it so that the content assist won't suggest unreachable variables and functions? If there is no way to accomplish this, then that is frankly a ridiculous flaw for an otherwise excellent IDE.
The funny thing is that yesterday it seemed that I got it to work by moving the source files to a different folder, but today, if I don't list the source folder in "C/C++ General -> Paths and Symbols -> Source Locations", I get unresolved inclusions in the source file (the indexer won't even resolve standard library functions), and if I do list the folder, then I'm back to square one and content assist suggests unreachable variables/functions again.
CDT does not present unreachables in code completions. The issue you are facing is the definition of unreachable AFAICT.
In C, everything that is not static is "public" and can be called from anywhere else. No declaration is even necessary (although I would recommend -Wall -Werror, but that is a separate discussion).
For example, consider file.c with contents:
static void func_private1(void) {}
static void func_private2(void) {}
void func_public1(void) {}
void func_public2(void) {}
if you request completions for func_ in file.c you get all the completions:
however, if you open another file and request completions for func_ you only get the public ones (non-static):
Now, in the other file, if you select func_public1, then you can have CDT automatically add in the header file for it. You can do this with "organizing imports" Shift-Ctrl-O (Source menu -> Organize Imports).
You can control the behaviour of Organize Imports in the preferences (C/C++ -> Code Style -> Organize Imports)
Related
I'm a beginner in C++ and in Eclipse, but I have a weird problem. My source and header files seem to act differently whether I imported them from someone or created them myself.
When I import a C++ file (header or source file) in my Eclipse IDE, the icon of the files on the window bar looks like this :
However, when I create a file on my own (File -> New -> Source File / Header File), the icon of the files I created look like this:
These files work the same as the first ones, the compiler works and the code executes properly, but it feels like Eclipse is considering the second files are in some way different from the first ones. I think this is causing some issues in the way Eclipse treats the syntax and coloring policy of my files, applying the policy to the first type of files and not to the second.
On the Project Explorer though, every file look the same :
Thank you in advance !
I have a C++ project built of several shared libraries. Each library source code is placed under its subtree of directories. The main CMakeList file contains a list of add_subdirectory(<dirname>) directives. CMakeList files in every subdirectory contain definitions like the following:
set (SOURCE_FILES
util/src/Connector.cpp
pub/util/Connector.h
)
add_library(channels SHARED $( SOURCE_FILES))
SET_TARGET_PROPERTIES(channels PROPERTIES LINKER_LANGUAGE CXX)
where channels is the subdirectory name.
Although the search path for include files is set correctly and compilation works, KDevelop does not see the Connector.h header file and, therefore, its parsing and code/class browser do not work.
I know that .kdev_include_paths file in every directory might solve the problem. Unfortunately, this approach may not be used due to some additional constraints in our development environment.
Is there any other way to solve this issue?
I use Intel C/C++ compiler on RHEL 7.1 with KDevelop 5.0.4 running from AppImage.
I found and solved a problem which presented similarly - header files not seen and code/class browser failing. The cause turned out to be an error in my code. For the benefit of others who may write a similar bug and arrive at this page, here is what I did wrong:
I had a header only class in a file 'myClass.hpp' and an empty implementation 'myClass.cpp'. My CmakeLists.txt cited the implementation, but my implementation did not contain #include "myClass.hpp". The effect in Kdevelop-5.1.0 was that the header file was not parsed as part of the program - hence its includes were not read, and much of the code failed semantic analysis.
On KDevelop 5 this solved my issue:
Go to menu "Project" -> "Open Configuration..."
In the window which now opens, go to "Cppcheck" on it's left side and then to "Include Directories" on it's right side
check the "Use 'system' include dirs" option:
Try adding
include_directories(${SOURCE_FILES})
It appears I experienced the same problem.
Symptoms:
-- Kdevelop 5.1.2 could not find some #includes; they were underlined in source files.
-- There was no problem building the project
Cause:
-- Both symbolic links and the original *.h files were in the paths specified in
include_directories( ) in CMakeLists.txt. Symbolic link removal fixed the problem.
Kdevelop is probably right to be confused about multiple *.h files with the same name.
Maybe some future Kdevelop release will be able to recognize that it is dealing with only one target.
I am trying to use CDT to edit C++ files. However, it refuses to see the std classes like string and vector.
(I will continue to build with make outside of eclipse, for now at least. The code compiles fine. But without a definition for string etc. almost everything is shown as an error in the editor.)
I am using Luna. CDT added to a Java oriented eclipse using Help > Install New Software.
The docs just say "install the the Tool Chains and stuff happens". But having spent several hours reading up on this, I think the phrase "Tool Chain" has several different meanings depending on the sentence. These include
The compilers and linkers themselves, e.g. minggw
Extra stuff (plugin?) added to Eclipse itself so that it can use those compilers.
Configuration within Eclipse itself
My make file uses
D:\cygwin64\lib\gcc\x86_64-w64-mingw32\4.8.3\include
but sometimes CDT seems to be pointing to
D:\mingw64\include\c++\4.5.4
Which is OK, as it will have the same .h files.
I have tried fiddling with PATH (to /bin), plus the Project Properties > > Environment MINGW_HOME. The "tool chain editor" mentions MingGW and says GCC C++, but I don't know what that really means and the easy-to-use interface does not show the paths.
I also tried adding D:\cygwin64\lib\gcc\x86_64-w64-mingw32\4.8.3\include to the Paths & Symbols > Include, but that does not help.
There is also "Libraries and "Library Paths". I do not know what the difference is (both want paths) but I am guessing this is for linking, not compiling. I am also guessing that the IDE parsing of the C++ during editing is done by CDT itself, and does not rely on external compilers.
A secondary question is how does CDT determine which header files are relevant? In general that is undecidable in C, in my case my header files rely on other header files that are loaded from the containing .cpp files. I am guessing that it just ignores the #include directives and loads up every header file it comes across, hoping that there are no conflicts.
My hack is as follows, after spending too much time trying to fix it properly and no posts here.
#ifdef ECLIPSE
// Dummy declarations to help with misconfigured Eclispse
class string{};
template <typename T>
class vector{
public:
unsigned size();
void push_back(T t);
T at(unsigned idx);
};
#endif
Yes, just trick Eclipse into thinking the classes are OK. I would not call this an answer though.
Strangely the class def of string seems enough to convince eclipse that casts to char * are OK.
(I access these classes with using, so no std::)
If CDT is unable to resolve standard library includes like <string> and <vector>, this is a sign that it cannot find your compiler.
Open a Command Prompt and type g++. Is it found? If not, it means the directory containing your compiler is not in the PATH environment variable. Add this directory (likely something like D:\cygwin64\bin) to PATH (how you do this depends on your Windows version, but it's something like Computer | Properties | Advanced system settings | Environment variables), then restart Eclipse and try again.
In one particular cpp file (abc.cpp), when I ask to navigate "to Declaration/Definition", it says "cannot open element "abc.h"". This functionality works for other header files. This in itself is not a big problem, but it also means that auto-complete and syntax highlighting doesn't work for this file.
Some extra info:
The header file is in the same directory as the cpp file and both are included in the active netbeans project
I was able to enter the header file name with auto-complete, i.e. #include "ab<ctrl-space>"
clicking the "Go to header/source" button works both ways for this cpp/h pair.
right-clicking on the class name in the header file, and then selecting "go to source" brings me to the cpp file, as usual.
in other cpp files the connection to the header file is working fine, as is autocomplete & syntax highlighting
netbeans has a green square in the top right of the header file window, indicating "no errors"
I have tried deleting my cache as explained here
I'm using netbeans v8.0.2 on OpenSuse 13.2
Here are some ideas:
Sometimes the Code Assistance is not as good for projects that Netbeans didn't create from scratch. If it is not a complicated Makefile, it might be worth it to create a new project with the C/C++ Application type and copy over and then add each source and header file.
The code assistance depends on analyzing he log from the build each time, so sometimes just rebuilding the project will fix the code assistance.
There are a number of options if you right click the project under the code assistance sub-menu.
Edit the Makefile to make sure this file is being compiled in the same way as the other files that work. It may be getting compiled with different options because it was added later and therefore not providing the same info for code assistance. You will need to rebuild after making these changes for them to have an effect.
I'm beginning to tear my hair out over this, so it's time to post here!
I have a C++ project in XCode, built as a Command Line Tool. All .cpp files have been renamed as .mm, there is one .hh and a few .h headers. I've specified 'Compile Sources As -> Objective-C++' in Build Settings.
I have another XCode project for an iOS app. This is set to 'Compile Sources As -> According to File Type'. I can't set it to compile everything as Objective-C++ since some parts of the project won't compile as Obj-C++.
There is one class in the iOS app where I wish to utilise my C++ project, and it consists of files MyClass.hh, MyClass.mm; they were simply .h and .m but I renamed them in the hope of remedying this problem.
I dragged my cpp project into the iOS project. I then added a Target Dependency in the iOS Build Phases to point to the cpp CLI application.
In MyClass.hh I have
#include "../path/to/CppProject/ImportAll.h"
..which is a header file that successively 'include's all headers from the cpp project. I then go about my business, creating one property within MyClass.hh which is a pointer to a cpp object, and various references within MyClass.mm to cpp classes.
The darn thing just won't compile though - I get a ton of messages relating to my cpp classes like this:
MyCPPFile.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token
Is the compiler not recognising that MyClass.hh is Objective-C++ not Objective-C? Should I have a target dependency which is a library instead of pointing to this CLI app, perhaps?
I've googled around for a while trying to solve the problem. I've seen references to people using
#ifdef __cplusplus
or else having to rename files to .mm to get things working, but in other cases people simply say they drag and drop projects across with no issues.
Can someone please enlighten me, and explain what key steps I should be performing to make this work? I'd be very grateful! Thank you.
Thanks to everyone who gave me suggestions.
Having created my projects anew from scratch, I fiddled and logic-ed my way to the solution. Note that - at least in my case - no use of #ifdef __cplusplus was required, nor any other preprocessor directive. Only file suffix changing is essential (as detailed below).
Here's the process:
Create C++ Static Library and Include/Link with Objective-C Library (e.g. iOS app) in XCode 4:
In XCode 4 create a New Project of type Cocoa Touch Static Library. Hereafter we shall refer to this project as 'CProj'.
In CProj workspace create/import as many C++ classes as required. No special suffix for filenames is necessary - all my files are .h and .cpp.
In XCode create/open any Objective-C project e.g. iOS app. Hereafter we shall refer to this project as 'ObjProj'.
Find CProj.xcodeproj in Finder (typically /Documents/CProj/CProj.xcodeproj), drag it onto the visible ObjProj project icon at the top of your XCode Project Navigator (visible file/folder hierarchy on left side in XCode). This now places CProj as a nested project within ObjProj.
Left click ObjProj project icon in Project Navigator, a new pane emerges to the right, left click Build Phases in this pane.
Under Target Dependencies click '+' icon and select CProj library icon below listed CProj project. Click OK.
Under Link Binary With Libraries click '+' icon and select CProj library icon from within Workspace collapsible folder at top of window presented.
File Renaming Rules
Where including a CProj header in ObjProj, use path backtracking to identify import, e.g. #include "../../MyProj/MyImport.h" to step 2 dirs backwards then step into MyProj folder.
Any ObjProj implementation file including a CProj header must be renamed from .m to .mm . Any ObjProj header file including a CProj header must be renamed from .h to .hh .
Any ObjProj file including a file whose suffix is now .hh (consequence of step above) must be renamed in the same manner.
An example:
Consider you have files A.h, A.m, B.h, B.m.
A.m imports B.h, and B.h includes one or more CProj headers. B.m includes type references, using CProj classes included via B.h .
First renaming is B.h -> B.hh since it contains includes.
Then B.m -> B.mm since it contains type references to CProj (no includes necessary since B.h has already done them).
Then A.m -> A.mm since A.m which contained an include for B.h now has an include for the renamed file, B.hh .
P.S. Note that the C++ library doesn't like to auto-rebuild when it should - I often have to 'Clean' then 'Build' in ObjProj after updating CProj from within it.
It sounds like the crux of your problem is this:
Is the compiler not recognising that MyClass.hh is Objective-C++ not
Objective-C?
The compiler is not recognizing that MyClass.hh is Objective-C++ code. Or any other code; the compiler never sees MyClass.hh (in all likelyhood).
By convention, header files are never passed to the compiler by default. Only the source files (.cpp, .m, et cetera) are -- the preprocessor that is run on those files results a translation unit that contains the original source file plus all the included headers and resolved macros.
So the problem is that you probably have a .mm source file that imports MyClass.hh, which in turn includes the C++ header file. But the compiler is trying to compile the resulting translation unit as Objective-C++ and encountering some C++-specific stuff in that header. In fact, I suspect that this problem has nothing at all to do with the additional target dependencies and such that you've got set up: I think you could reproduce it minimally with a very simple Objective-C++ application that includes the header. You should try that and see, it will either confirm my theory (after all I'm just speculating since you haven't shown enough source for me to know for sure) or indicate that the problem is elsewhere.
The solution is probably to use preprocessor guards like #ifdef __cplusplus (there's a useful catalog of predefined symbols here) to hide the C++-specific code from the Objective-C++ compiler (or the other way around in some cases). Note that this may be difficult to impossible to do based on the actual content of the header.