I have vim and clang_complete installed but for some reason when I try to auto complete it doesn't see some of OpenGL's functions, such as glBindBuffer, or glEnableVertexAttribArray. I press CTRL + X and CTRL + U to force the auto complete and it shows the function names and parameters, but it's just missing some of the functions.
Even with glfw, I try auto completing GLFW_KEY_ESC but it's not there, I don't know why, it just says User defined completion (^U^N^P) Pattern not found
Does anyone have a solution to this problem? It's very annoying because I use these functions a lot and need the auto complete.
Thanks.
EDIT: Also my include header files are this:
#include <iostream>
#include <string>
#include <GL/glew.h>
#include <GL/glfw.h>
#include <glm/glm.hpp>
I'm on Arch Linux x64 by the way.
All right I found the answer. Because of clang_complete not being able to complete the arguments created by GLEW (because the functions are defined as #define FOO somefunction, and not defined as: #define FOO(arg1, arg2, arg3) someFunction(arg1, arg2, arg3))
To fix this, you have to add this option to your ~/.vimrc file.
let g:clang_complete_macros = 1
Now, you'll get function completion, but still no argument completion. So, you'll have to replace GLEW (sadly) with
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
This will finally complete the arguments, although, if there's an alternative to doing fixing this problem, I'd like to hear.
To expand on zero57's answer.
You could add a clang_complete specific compile flag to define a macro for clang_complete
let g:clang_user_options = ' -DCLANG_COMPLETE_ONLY'
Then in your code you could use
#ifdef CLANG_COMPLETE_ONLY
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
#else
#include <GL/glew.h>
#endif
This isn't a perfect solution but clang_complete should now complete your parameters and when compiling you will be using glew. This worked for me with the YouCompleteMe (YCM) plugin so I assume it works with clang_complete.
Related
Compiling with g++ (from Makefile generated with qmake) using the line
#if !QT_CONFIG(printer)
// do something
#endif
gives a preprocessor error on both g++ (7.3.0)
test.cpp:25:6: error: division by zero in #if
#if !QT_CONFIG(printer)
and clang (6.00)
test.cpp:25:6: error: division by zero in preprocessor expression
#if !QT_CONFIG(printer)
^~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:84:30: note: expanded from macro 'QT_CONFIG'
#define QT_CONFIG(feature) (1/QT_FEATURE_##feature == 1)
~^~~~~~~~~~~~~~~~~~~~~
1 error generated.
where clang++ gives the more detailed output. printer is not enabled, thus the macro as recommended to do conditional compilation. The QT version is 5.9.5. Any suggestions (wrong usage?) appreciated.
I don't think you should focus on that macro. The point of that macro is to simply crash your compilation code when QT_FEATURE_printer is zero. The code was not designed to work otherwise.
Instead of using the macro conditionally try to find out why QT_FEATURE_printer is zero and include / configure dependencies to change that (it seems to be definend in printsupport/qtprintsupport-config.h).
This is what happens if you have updated your qt sources to something using a new feature without running configure again. When you run configure the new features are set.
This is fixed in Qt 5.12.3. The newer version of notepad.cpp begins:
#include <QFile>
#include <QFileDialog>
#include <QTextStream>
#include <QMessageBox>
#if defined(QT_PRINTSUPPORT_LIB)
#include <QtPrintSupport/qtprintsupportglobal.h>
#if QT_CONFIG(printer)
#if QT_CONFIG(printdialog)
#include <QPrintDialog>
#endif // QT_CONFIG(printdialog)
#include <QPrinter>
#endif // QT_CONFIG(printer)
#endif // QT_PRINTSUPPORT_LIB
#include <QFont>
#include <QFontDialog>
I am using Visual Studio Community 2017 to code c++. When I run the following code everything works fine.
#include "pch.h"
#include<Windows.h>
#include<Psapi.h>
#include <iostream>
#include <conio.h>
int main()
{
std::cout << "Really!! How do you do it?";
_getch();
}
But if I change the order of #includes by including psapi.h before Windows.h, compiler goes badass and throws 198 errors at me, which surprisingly(maybe only to me) includes Identifier "BOOL" is undefined.
Why is this happening?
Since Psapi.h's include tree is trivial, I'm going to exemplify. Everything relies on VStudio 2015 (Community) (v14.0.25431.01 Update 3) and Windows Kits 8.1 (? funny, because v10 is there too) files (with default env vars and preprocessor definitions):
BOOL is defined in minwindef.h (#157: typedef int BOOL;)
Psapi.h only includes one file (#27: #include <winapifamily.h>)
winapifamily.h doesn't include any other file
So, when reaching Psapi.h (#87: BOOL WINAPI EnumProcesses (...), the compiler doesn't know anything about BOOL, so it complains.
Windows.h includes minwindef.h (indirectly, via windef.h), and that's why it works when you include it before Psapi.h.
Personally, I think it's a bug in Psapi.h, since it's not self contained, but there might be a good reason (that I'm not aware of) for that. Anyway, if this is indeed a bug, it wouldn't be MS's 1st one :)
#include <Windows.h>
#include <WinSock2.h>
// main present just for rigorosity's sake
int main() {
return 0;
}
to answer the question, I know this is DATED but the issues persist today. You need the following:
#include "stdafx.h"
#include <stdbool.h>
#include <Windows.h>
#include <stdlib.h>
#include <psapi.h>
After stdlib.h was included, the errors were gone.
As per this answer, I tried printing a uint64_t, but it gives me an error:
error: expected ``)' before 'PRIu64'
Following is the minimal code showing what I am trying to do:
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
#include <cstdio>
class X {
X() {
uint64_t foo = 0;
printf("%07" PRIu64 ": ", foo);
}
};
int main() {}
This minimal code compiles, but my actual code does not. However, I have tried with the 2 lines inside X::X() exactly the same in my actual code, and that does not work.
What should I look for to debug this further? My actual code also #includes other headers. Could that be causing the problem? Does order of including the headers matter?
Edit
PRIu64 is defined as follows on my machine:
# if __WORDSIZE == 64
# define __PRI64_PREFIX "l"
# define __PRIPTR_PREFIX "l"
# else
# define __PRI64_PREFIX "ll"
# define __PRIPTR_PREFIX
# endif
# define PRIu64 __PRI64_PREFIX "u"
In C++ the macros are not automatically defined just by including the file.
You need to add the following:
#define __STDC_FORMAT_MACROS 1
before
#include <inttypes.h>
How to printf uint64_t? Fails with: "spurious trailing ‘%’ in format"
One other possibility for this issue I just found in my own code is if another header already pulls in <inttypes.h> before you define __STDC_FORMAT_MACROS. For example:
Utils.h (Perhaps originally written for C, as it was in our case):
#include <inttypes.h>
// ... Function declarations
MyFile.cpp:
#include "Utils.h"
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
Since inttypes.h has already been included by Util.h, the compiler doesn't include it again, and doesn't see the declaration of __STDC_FORMAT_MACROS.
The solution is either to edit Utils.h to include #define __STDC_FORMAT_MACROS, or to make sure to define it before doing any includes in MyFile.cpp.
#define __STDC_FORMAT_MACROS
#include "Utils.h"
#include <inttypes.h>
The original setup actually compiled just fine on GCC 4.8 on Ubuntu, but failed with an old ltib GCC 4.3 toolchain for PowerPC, which made it all the more perplexing at first.
PRIu64 is not defined where you use it.
Replace it with the string "llu" and your code will compile (but that is not a fix, it just demonstrates the problem)
Maybe the include is missing. Maybe over zealos include guards and it being included without the magic token block the define. Maybe your pch is busted.
If you are on android JNI platform. Put this in your Android.mk:
LOCAL_CPPFLAGS := -D__STDC_FORMAT_MACROS
When i include GdiPlus.h,Pen class is undefined.
But GdiPlus.h includes GdiPlusPen.h
...
#include "GdiplusImageAttributes.h"
#include "GdiplusMatrix.h"
#include "GdiplusBrush.h"
#include "GdiplusPen.h"
#include "GdiplusStringFormat.h"
#include "GdiplusPath.h"
...
When i include GdiPlusPen.h myself, it works. Can i use it safely?
Question: is this because of my VC++ being express install?
8 days left until activation prompt :(
Anyone having same problem?
Windows XP sp-3, pentium-m centrino.
No, #including GdiplusPen.h directly isn't correct. The gdiplus classes live in a namespace named "Gdiplus". Either use that namespace explicitly (like Gdiplus::Pen) or make it look like this in your .cpp file:
#include <gdiplus.h>
using namespace Gdiplus;
I'm trying to link GLEW (with SDL and OpenGL - note, not SDL's implementation of OpenGL) in Qt Creator via a QMake file, though I'm not having much luck. No matter what I try, I seem to get the same string errors which deals with conflicting declaration problems stemming from a few typedefs. What I'd like to know is why this is happening, along with what can be done about it.
Example
/usr/include/SDL/SDL_opengl.h:4855: error: conflicting declaration ‘typedef void (* PFNGLFRAGMENTLIGHTFVSGIXPROC)(GLenum, GLenum, const GLfloat*)’
/usr/include/GL/glew.h:12201: error: ‘PFNGLFRAGMENTLIGHTFVSGIXPROC’ has a previous declaration as ‘typedef void (* PFNGLFRAGMENTLIGHTFVSGIXPROC)(GLenum, GLenum, GLfloat*)’
Is this because I'm linking with SDL (seeing as how it has OpenGL support), or is there something else going on here?
Qmake File
QT += core
LIBS += -lSDL -lSDL_image -lopengl32 -lGLU -lGLEW
stdafx.h
#pragma once
/*************/
/* #includes */
/*************/
//GL / SDL
#include <GL/glew.h>
#define GLEW_STATIC
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glext.h>
#include <SDL/SDL.h>
#include <SDL/SDL_opengl.h>
//STD
#include <iostream>
#include <fstream>
//Qt
#include <QListIterator>
#include <QMapIterator>
#include <QVector4D>
#include <QColor>
/********************/
/* Using Statements */
/********************/
using std::cout;
using std::endl;
using std::cin;
using std::fstream;
stdafx.cpp
#define GL_GLEXT_PROTOTYPES
The only solution to your problem is not to use one (either GLEW, or SDL_opengl), or at least do not include both GL/glew.h and SDL/SDL_opengl.h headers in any source or header file.
I have had similar issues before which we "solved" by defining NO_SDL_GLEXT before the inclusion of <SDL/SDL_opengl.h>, so:
#define NO_SDL_GLEXT
#include <SDL/SDL_opengl.h>
I say "solved", because it made the errors go away, but I never investigated possible side-effects or problems (we ended up moving away from SDL shortly after that and never really used it anymore). Perhaps worth a try...