I have to develop my project in text-mode debian linux. I'm using Vim and I installed the clang_completion plugin on it. I made .clang_completion file in root of my project :
-I.
-I/usr/include
-I/usr/include/c++/4.6
When I write a program like below, the completion works fine.
//#include <stdio.h>
int main()
{
struct A
{
int x, y;
};
A a;
a. // After putting dot, the suggestion popup appears
return 0;
}
However, after removing the comment of first line, it doesn't work! How can I overcome this issue?
I found the easiest way to get clang_complete to work is to use the provided cc_args.py file.
when compiling a project use clang_complete/bin/cc_args.py instead of gcc/g++
This will generate the correct .clang_complete file with all libraries and dependencies.
Provided the clang_complete source directory in your home folder.
Example Makefile:
CXX=$(HOME)/clang_complete/bin/cc_args.py g++
all:
$(CXX) main.cpp
I've successfully used the clang_complete plugin in the past (now I just use cscope and ctags, which I consider enough).
Including external headers worked fine in my configuration, but, as the clang complete plugin page specifies, the file in which to put include paths (or any other flag you may want to pass to the clang compiler), must be named .clang_complete and not .clang_completion.
Also, I used to put the options on a single line, just as I was going to pass the plain content of the .clang_complete file as a command line option (don't know if separating lines with \ will work).
Hope this helps.
Related
I need to run a demo program, ba_demo.cpp, which is in a folder structure, "C:/root/demo_parent1/demo_parent2/demo.cpp", and this file uses the following code in it.
#include "root/sub1/sub2/header_file.h".
The file is at
'C:/root/sub1/sub2/header_file.h'
When I try to compile the demo program by the command
C:\root\demo_parent1\demo_parent2> gcc demo.cpp
it is not finding the header file and is throwing an error. What changes should I make to my command in order to run the demo program successfully?
First you must inform your compiler where to look for root directory by adding flag -IC:
so your command will look like this:
C:\root\demo_parent1\demo_parent2> g++ demo.cpp -IC:
But that's not practical. Better change include to
#include header_file.h
and add only /root/sub1/sub2/ directory, which will look like this:
C:\root\demo_parent1\demo_parent2> g++ demo.cpp -IC:\root\sub1\sub2\
Now you have your program compiled to a.out file. You execute it by
C:\root\demo_parent1\demo_parent2>./a.out
You can change output name to demo.exe like this:
C:\root\demo_parent1\demo_parent2> g++ demo.cpp -IC:\root\sub1\sub2\ -o demo.exe
Please note that since you work on Windows under some &nix simulator the slashes in my examples might be wrong but I can't check them now. Use google to check how to handle them properly.
EDIT: Also, don't forget to take Lukas Holt's advice and use g++! It is very important to use proper compiler for proper language.
Your .cpp file is in: C:/root/demo_parent1/demo_parent2/demo.cpp
You include:
#include "root/sub1/sub2/header_file.h"
This is a relative path. You need either to specify an include directory with the -I flag, or to move header_file.h to C:/root/demo_parent1/demo_parent2/root/sub1/sub2/header_file.h.
The most simple solution would be to just #include "header_file.h" and to move it into the same directory as demo.cpp.
Then you will be able to compile it with gcc, and to execute the generated file.
I tried to search this question online, but it seems that I can't find a good solution for my problem. Well, I'm trying to use gdb to debug my c++ program. And the program is made up of a simple main.cpp and a model.h. And the compiling command is
g++ -Wall -g -c main.cpp
g++ -Wall -g main.o -o OUTPUT
As almost all the algorithm is stored in model.h, I need to debug that header file rather than the cpp file. However, whenever I tried to place a break point on the header like
tbreak model.h:163
gdb always give me a message that"No source file named TNFmodel.h".
In another question breakpoints in GDB, I saw a solution by adding the folder that containing the header into the library by "dir". But my header file is already in source folder, and after trying
dir ./
The problem maintains.
So anybody know what's wrong? How to use gdb to debug a header file?
As suggested by https://stackoverflow.com/users/760746/nobody, one way to make sure the header to be in the sources is to veryfy it by checking
info sources
After ensuring the header itself be in the sources(in my case, the problem is that the case of a letter in the header name was mixed up, and somehow it went through the compiling on my mac book), inserting breakpoint in lines of a header file works just fine.
Try to use break with your class/method name like this:
break class::method
What I've found is that is that the file names are sometimes shortened. Using info sources I was able to find the shortened name that GCC used. When I set the breakpoint using the shortened file name, GDB correctly set the breakpoint.
For example the file CommonLibrary\headers\Endian.h was changed to COM~2\headers\Endian.h
This on Windows 10, running mingw-64.
It's been a while since I've dealt with C/C++, so forgive me if this is a ridiculously easy to answer question - I just don't quite know how to "Google" it.
I have a file, "MyFile.h" that includes file "includedFile.h". However, the compiler cannot find the file. Please see below picture:
What I'm doing is moving the project from an old Solaris box to a Linux box. The weird thing is that it worked on the Solaris box as-is but Linux is a little confused.
The makefile that I use for the project hasn't changed either which makes me think that it may be a compiler option...
So how do I tell the compiler on Linux where that include file is, or how do I specify it in "MyFile.h?"
With gcc and clang, you specify the include path using -I:
g++ -o myprogram main.cc extra.cc -I/usr/include/boost -I/my/extra/include/files
You can specify full paths in your files, as in #include "/path/to/my/includedfile.h", but I strongly discourage this as it forces everyone who wants to compile your code to comply with that directory layout.
Also relevant: Read the following link for the difference between #include <file> and #include "file" in gcc: http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html
Assuming you are using g++, you pass a path with the -I flag.
g++ ..... -I<a path to your includes> -I<another path to includes>
I'm trying to use libjson within a C++ project and the docs tell me to just "add libjson's source to your project, comment JSON_LIBRARY in the JSONOptions.h file and any C++ compiler should compile it."
Being quite new to C++ and all that, how exactly am I supposed to do that (not using any IDE)? Should I just #include the libjson.h file and that's it? Shouldn't I reference libjson somehow in my call to g++ when compiling my project?
thx in advance
If you go into the libjson library folder, you will see a makefile. Navigate to that directory in a terminal and type:
make
then
make install
Then, in your code
#include <libjson.h>
or, depending on your include path:
#include <libjson/libjson.h>
That should be all that you need to do.
If you need additional help, you can post in the help forum at sourceforge (I am the author of libjson)
You have to:
One,
#include <libjson.h>
in order to get access to the functions and data types the library offers, then
Two, link against the libjsonz library:
g++ -o myprogram myprogram.c -ljson
(the -ljson flag has to come last or you'll get a linker error with never versions of GCC.)
EDIT: if you need to build the library, you typically have a configure script or a Makefile. See how to use them.
if you install json you should find include file at /usr/local/include
so
#include <json/json.h>
gcc exasmple.c -ljson
I'm experiencing an extremely weird problem in a fresh OSX 10.4.11 + Xcode 2.5 installation. I've reduced it to a minimal test case. Here's test.cpp:
#include "macros.h"
int main (void)
{
return 1;
}
And here's macros.h:
#ifndef __JUST_TESTING__
#define __JUST_TESTING__
template<typename T> void swap (T& pT1, T& pT2)
{
T pTmp = pT1;
pT1 = pT2;
pT2 = pTmp;
}
#endif //__JUST_TESTING__
This compiles and works just fine if both files are in the same directory. HOWEVER, if I put macros.h in /usr/include/gfc2 (it's part of a custom library I use) and change the #include in test.cpp, compilation fails with this error :
/usr/include/gfc2/macros.h:4: error: template with C linkage
I researched that error and most of the comments point to a "dangling extern C", which doesn't seem to be the case at all.
I'm at a complete loss here. Is g++ for some reason assuming everything in /usr/include/gfc2 is C even though it's included from a .cpp file that doesn't say extern "C" anywhere?
Any ideas?
EDIT : It does compile if I use the full path in the #include, ie #include "/usr/include/gfc2/macros.h"
EDIT2 : It's not including the wrong header. I've verified this using cpp, g++ -E, and renaming macros.h to foobarmacros.h
G++ may well indeed be assuming that everything in /usr/include is C. Try compiling your code with -E and studying the line markers in the preprocessor output:
g++ -E test.cpp | grep '^#'
You'll likely see things like
# 1 "/usr/include/gfc2/macros.h" 1 3 4
The 4 is the preprocessor hinting to G++ that it should wrap everything in extern "C", on the supposition that your platform's ancient header files in /usr/include predate C++. See Preprocessor Output in the CPP manual.
These days G++ mostly ignores this hint, because most platforms' C headers are no longer ancient. See the NO_IMPLICIT_EXTERN_C target macro in the GCC Internals manual. But it may be that this old version of Xcode has GCC configured without NO_IMPLICIT_EXTERN_C and thus is listening to the preprocessor's hint. (This is set when GCC itself is built -- I don't think there's a command-line switch to override it.)
You may be able to work around this by wrapping the contents of your header file in extern "C++".
This is a shot in the dark, but is there another file named macros.h somewhere under /usr/include or in your GCC installation? GCC has a facility for wrapping headers, called #include_next, which might be the cause of your problem.
One thing you can do to disambiguate your macros.h from any other macros.h in the include path is to include it as gfc2/macros.h. This way, the compiler will search every directory in the include path for a subdirectory named gfc2 containing a file named macros.h, reducing the chance of a collision. It also prevents you from having to add /usr/include/gfc2 to the include path.
BTW, #include "file.h" searches the current directory first. To skip that and go straight to the include path, use #include <file.h>:
#include <stdio.h>
#include <gfc2/macros.h>
Another approach is to choose a filename that is more likely to be unique, like gfc2macros.h.
Well, it really looks weird...
How does XCode calls g++?
I don't think g++ spontaneously decides that an include file has C linkage just because it's in a different directory. Did you try to compile your project by hand?
Try "g++ main.cpp -I/usr/include/gfc2/". If this solves your problem than it's not g++. Maybe does XCode precompile headers?
Have you tried not changing the test.cpp file at all, but instead when you compile also say:
-I/usr/include/gfc2/
You can see where g++ is looking for includes with the verbose flag:
g++ -v -o test test.cpp
And this will just run the preprocessor and show what is actually included in the file and compiled:
g++ -E test.cpp | less
If the wrong files are getting included (or your header is getting wrapped in another, as bk1e suggests) you'll be able to find out with that output.
I just ran into this issue as well when compiling a C++ project that we normally build on 10.5 and 10.6 (Xcode 3.0+) on a 10.4 PPC machine with Xcode 2.5 installed. It looks as if the preprocessor treats anything added to the gcc include path with '-isystem' as if it should be "extern C". Changing '-isystem' to '-I' resolved the issue.