c++ + opengl in visualstudio [duplicate] - c++

I'm using Visual Studio 2010 Express. When I use certain variable names, like "near, "far", "IN", "OUT", I can't compile: I get syntax errors located after the variable name used.
Example:
z = 1.0/(far - near);
Error:
error C2059: syntax error : ')'
How can I disable this "feature"?

far and near were built-in compiler keywords back in the 16-bit days. They no longer exist and they no longer have any meaning, but they're still defined as macros in the Windows headers for backwards compatibility reasons.
If you don't want them, just undefine them (or don't include the Windows headers):
#undef far
#undef near

Related

glbinding, Qt and error "glbinding is not compatible with gl.h"

I'm writing a new project and want to replace GLEW with glbinding.
My setup is like this:
VS 2015, Qt 5.6, glbinding 2.0
I tried to compile quite simple code - only window (QWindow) with OpenGL context (QOpenGLContext) but got an error: glbinding is not compatible with gl.h
When I was tracking this bug I found out that file (which is imported by the glbinding/gl/gl.h) nogl.h is causing this message with the code below:
#ifdef __gl_h_
#error "glbinding is not compatible with gl.h"
#else
#define __gl_h_
#endif
Then I noticed that this is caused by the QtGui/qopenglcontext.h header (which I need for creating OpenGL context...). So when I don't include qopenglcontext.h my program compiles without error. I also noticed that this error message appears only when I include glbinding/gl/gl.h after QtGui/qopenglcontext.h. If I reverse the include order I get a bunch of errors like this:
1>C:\Qt\Qt5.6.0\5.6\msvc2015_64\include\QtGui/qopenglext.h(117): error C2065: 'GLenum': undeclared identifier
1>C:\Qt\Qt5.6.0\5.6\msvc2015_64\include\QtGui/qopenglext.h(117): error C2146: syntax error: missing ')' before identifier 'mode'
1>C:\Qt\Qt5.6.0\5.6\msvc2015_64\include\QtGui/qopenglext.h(118): error C2065: 'GLenum': undeclared identifier
1>C:\Qt\Qt5.6.0\5.6\msvc2015_64\include\QtGui/qopenglext.h(118): error C2146: syntax error: missing ')' before identifier 'target'
After all I still don't know how to solve this and what exactly is causing this error...
glbinding – like practically every other OpenGL loader – has to fiddle with the OpenGL symbol tokens to avoid namespace clashing. To this end it must interact with the OpenGL definitions in a specific way, which means you must not have included any OpenGL header, or something that includes such in turn at the moment you include the glbinding header. The preprocessor fiddling glbinding performs will prevent gl.h getting included in a way that causes trouble.
So what you must do is: Include the glbinding headers in your C++ compilation unit files before everything else (Qt headers, OpenGL helper libraries and so on).

MSVC 2010 project-wide macro with parameters

I'm trying to create a Visual Studio project for code that contains
DL_EXPORT(void) initlua(void);
So I basically need a macro like
#define DL_EXPORT(retVal) __declspec(dllexport) retVal
Which works, but is OS/Compiler-specific, so I want to put that in the project*. But I can't figure out what to put in Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions (or in the Command Line) to do that. I'd think either of these would work:
DL_EXPORT(retVal) __declspec(dllexport) retVal
DL_EXPORT(retVal)=__declspec(dllexport) retVal
I'm leaning towards the latter, but neither seems to work - when compiling I get these errors:
error C2061: syntax error : identifier 'initlua'
error C2059: syntax error : ';'
error C2059: syntax error : 'type'
And compiling with /P to get the preprocessor result explains why: Nothing happened, so the compiler interpreted it as int DL_EXPORT(void) and expects a ;.
What is the right syntax for the definition? Or is there none, as people in this question assumed?
Thanks.
* I'm not using a simple #ifdef-check for MSVC because I'm just trying to create a Visual Studio project for an existing library (lunatic python) with existing build scripts that I don't want to break. Although I could admittedly use #ifndef DL_EXPORT - but I'd still like to know if I'm missing something or if this is just impossible to do in Visual Studio.
I think it should be possible to use /FI on the commandline to specify an include file to include automatically in every source file. In that file you put the #define statements you need.

c++ pragma #error giving an error

I recently came across a piece of code which uses
the pragma directive
#error Error ! Define [_HOS_ | _HOS_OV_ | _HOV_].
This code is from the ADOC-C jacobian computation routine.
The problem is that in C++ visual studio 2010 there is a curly red line below the #error indicating there is some problem within that line.
The code also fails to compile giving error message at that line
Is there a syntax issue or are those [_HOS_ | _HOS_OV_ | _HOV_] not defined at that point, and intelliSense knows that resulting in curly red line indicating some problem?
The author of that code intended to have an error when not at least one of the tags named in the error message is defined. You should have a look at the documentation of the ADOC-C stuff if s.th. is mentioned there about these tags.
The intent of the #error directive is to create compile errors. It's usually a way for the programmer who wrote the code to tell the programmer that's trying to compile and use it "You did something wrong, this won't work!". The string following the directive is the message that should be shown to the programmer trying to compile the code.
You should check what directives are around this one, for example are there any #ifdefs that cause it to be executed. Then you should lookup the conditions in which they executed (e.g. not defining the things the error lists) and look for a way to make them go away.
The problem is that in C++ visual studio 2010 there is a curly red line below the #error indicating there is some problem within that line.
Visual Studio 2010 does not recognize #error preprocesor syntax anymore. It only recognize #pragma warning

CMFCButton compilation error

I want to use a CMFCButton. When I compile, I get this error:
afxbutton.h(183): warning C4003: not enough actual parameters for macro 'SelectFont'
afxbutton.h(183): error C2226: syntax error: unexpected type 'HFONT'
It seems to be in conflict with a windows macro:
Windows SelectFont() Macro
How can I fix this ?
SelectFont is defined in Windowsx.h. To resolve the conflict, find any #include for Windowsx.h in your project and move it after the #include for the MFC controls. Maybe to the end of your stdafx.h.
The same problem can be seen here (note BCGSoft is the company that created the MFC controls, so the same situation applies)

iphlpapi / ifdef.h

I'm trying to use iphlpapi (GetAdapterInfo) and am having trouble compiling the code. I have iphlpapi.h from SDK 7 and have added the appropriate path to the include files in visual studio.
I get the following error...
c:\program files\microsoft sdks\windows\v7.0\include\ifdef.h(154) : error C2146: syntax error : missing ';' before identifier 'NET_IFTYPE'
The lines in ifdef where this occurs are shown below.
typedef NET_LUID IF_LUID, *PIF_LUID;
typedef ULONG NET_IFINDEX, *PNET_IFINDEX; // Interface Index (ifIndex)
typedef UINT16 NET_IFTYPE, *PNET_IFTYPE; // Interface Type (IANA ifType)
I finally figured out how to get this to work so I'm putting this here for others who might stumble upon it.
First, I'm using visual c++ version 6.0 with the 2003 sdk. I added the sdk as the first choice using TOOLS->OPTIONS->DIRECTORIES. Adding the include winsock2.h caused about 60 redefinition errors. I found several sources telling me that the winsock2 include had to precede the windows.h include. My windows.h include was generated for me by VC++ in the precompiled header stdafx.h so I moved the winsock2.h include there. I now can compile and run my program!
According to this page, it looks as though you might need to make sure winsock2.h is included first. I'm guessing that it defines some of those types.
Also, the MSDN page for NET_LUID says it requires Vista at a minimum. Make sure that's true.