I just tested the code in chapter 1 (OpenGL 4.0 Shading Language Cookbook)
I have installed Qt5, qmake -tp vc chapter01.pro then open it in vs2010.
Built and got many errors like:
1>D:\APP\Qt5\5.0.0\msvc2010\include\GLES2/gl2.h(38): error C2371: 'GLintptr' : redefinition; different basic types
1> D:\OpenGL\glew-1.5.4\include\GL/glew.h(1615) : see declaration of 'GLintptr'
1>D:\APP\Qt5\5.0.0\msvc2010\include\GLES2/gl2.h(39): error C2371: 'GLsizeiptr' : redefinition; different basic types
1> D:\OpenGL\glew-1.5.4\include\GL/glew.h(1614) : see declaration of 'GLsizeiptr'
1>D:\APP\Qt5\5.0.0\msvc2010\include\GLES2/gl2.h(96): warning C4005: 'GL_BLEND_EQUATION_RGB' : macro redefinition
1> D:\OpenGL\glew-1.5.4\include\GL/glew.h(1666) : see previous definition of 'GL_BLEND_EQUATION_RGB'
1>D:\APP\Qt5\5.0.0\msvc2010\include\GLES2/gl2.h(474): error C2365: '__glewActiveTexture' : redefinition; previous definition was 'data variable'
1> D:\OpenGL\glew-1.5.4\include\GL/glew.h(12027) : see declaration of '__glewActiveTexture'
1>D:\APP\Qt5\5.0.0\msvc2010\include\GLES2/gl2.h(475): error C2365: '__glewAttachShader' : redefinition; previous definition was 'data variable'
How to solve these problems? (The code link is here)
Short answer: only include GLEW's header file, and don't include any OpenGL headers.
Explanation: GLEW's header file effectively includes everything in the OpenGL header files (I've never tried with GLES, but I suspect it's the same), redefining all of the OpenGL entry points through C preprocessor macros. This is why you're seeing the multiply-defined symbols and types. Additional information can be found here.
Not a best answer for sure, but I've just checked the book.
It seems that book is outdated when you get to Qt's version:
For example, in recent versions of Qt (at least version 4.7)
So, for the sake of easy reading the book, you may consider to downgrade your Qt to 4.x (4.8, for example) family, as there may be a lot of changes in the OpenGl requirements, especially if Qt build you are using is built with different OpenGl libraries.
Another solution is to use updated source code which doesn't require Qt at all:
This is the example programs from the OpenGL 4.0 Shading Language Cookbook, by David Wolff. The source code has been updated to work with MS Visual Studio, and no longer requires Qt.
Related
I am using VS 2017 Community edition, Intel Compiler 17.00 update 6 and and boost 1.66, trying to learn my way around boost::multiprecision::float128. Literally taking the example code from here and putting it in a new project for VS.
Compiling gives multiple errors, in roughly two categories/files:
In float128.hpp:
three errors of "error : identifier "xxx" is undefined" for fmaq, remquoq and remainderq. Indeed I am not able to find definitions for them - a missing include?
the global scope has no "signbitq" - this again looks like missing definition (i.e. the same as above)
For GCC the above functions are found within quadmath.h, however, the boost header doesn't seem to include it when using ICC (i.e BOOST_MP_USE_QUAD is set).
In C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\xutility: an explicit template argument list is not allowed on this declaration. There are three counts
I assume that i need to remove something that has been put in by default from the VS, but I am at a loss what exactly.
Thank you for your help
EDIT: Errors #2 above are actually not against boost at all (should I move this to a separate question?).
The following code copied from here! is not being compiled in my setup:
#include <iostream>
#include <string>
int main() {
std::string str("Test string");
for (std::string::iterator it = str.begin(); it != str.end(); ++it)
std::cout << *it;
std::cout << '\n';
return 0;
}
The exact error (one of them) is:
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\xutility(680): error : an explicit template argument list is not allowed on this declaration
1> _INLINE_VAR constexpr bool _Is_iterator_v<_Ty, void_t<_Iter_cat_t<_Ty>>> = true;
1> ^
1> detected during:
1> instantiation of "const bool std::_Is_iterator_v [with _Ty=char *, <unnamed>=void]" at line 520 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"
1> instantiation of "std::basic_string<_Elem, std::char_traits<_Elem>, std::allocator<_Elem>> std::_Integral_to_string<_Elem,_Ty>(_Ty) [with _Elem=char, _Ty=int]" at line 554 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"
I found this which indicates that there could be a problem with the particular versions used (ICC- 17.0 Up6 and VS 15.6), however i cannot really move to new intel compiler and i cannot test VS 15.4
I would like to write down how I managed to deal with error #2 from the original question, as it might be useful to someone.
Just as a reminder, the second errors I was seeing were in xutility. With the help of everyone that provided suggestions, it turned out that icc was in fact failing on very simple code - the following is enough to "break" it
int main() {
std::string str("Test string");
}
I have posted the question to intel's forums, however so far I have not received answers (for the 17.0 version of the compiler). Link here if anyone is interested.
That said, I came upon this blog post from the VC++ team, showing that the base toolset shown as v141 in VC2017 actually has had several minor revisions. It is possible to change the version of the MSVC toolchain but this needs to happen via editing of project files (rather than UI parameter changes).
My testing shows that version 14.11 (which is part of VS2017 15.3 and 15.4) works for Intel 17.0 while versions 14.12 and 14.13 (the last one is the current default for VS2017 15.6.4) do not. This has been done for Update 6 of the compiler. So in order to use the intel compiler on windows with visual studio, one needs to use particular MSVC toolchain versions.
Side note: I also installed icc version 18.0 update 1 for testing -- it too was giving compiler errors (and not just for me this time). The reason there though can be linked to some internal issue for icc, per this forum post. I can confirm that removing the compiler option /permissive- from the compiler fixes the errors irrespective of the base toolchain. Using v14.11 as base toolchain also fixes this particular problem for me with or without the option. /permissive- is a new option for icc (it is not part of 17.0).
The above solves more or less the second part of my problem with the icc. The rest of the question (boost's float128) though still remains. I will add more if i hear from boost's guys.
EDIT: the errors coming from boost turned out to be an issue there -- it was fixed by the maintainers in development branch, so this is resolved as well.
For Error #1, I got the same thing. However, after commenting the code blocks in boost float128.hpp where those four functions invoked, the float128 example code can be compiled with success. The side effect is unknown. I'm looking forward a revision on boost::multiprecision::float128.
I'm porting a c++ Dll with MSVC 2010 from 32- to 64 bit.
Therefore I changed the qt version it uses from qt 4.3.5 to qt 5.2.1.
It seems, that they changed some things, because I receive the following errors when I try to compile:
cpp(116): error C2039: 'latin1' : is not a member of 'QString'
cpp(477): error C2039: 'extension' : is not a member of 'QFileInfo'
cpp(518): error C2660: 'QFileInfo::baseName' : function does not take 1 arguments
cpp(824): error C2039: 'setIcon' : is not a member of 'QWidget'
I've looked in the qt porting guidelines, but didn't find anything specific to the above problems.
Any hints welcome.
I think, all mentioned functions come from Qt3 and were in Qt4 along with Qt3Support libraries for compatibility reasons. What you need to do now, is just replacing them with equivalent functions from Qt5 API. For example:
QWidget::setIcon() -> QWidget::setWindowIcon()
QFileInfo::extension() -> QFileInfo::suffix()
etc.
i've just started to learn the basics of HLSL using C++, im following the tutorials on a book, the first basic shader is:
float4 VS_Main( float4 pos:POSITION):SV_POSITION
{
return pos;
}
but i get a lot of errors at compile time:
error C2146: syntax error: ';' missing before the identifier 'VS_Main'
error C4430: missing type specifier, int assumed. Note: default-int is no longer supported
error C2146: syntax error : ')' missing before the identifier 'pos'
error C2059: syntax errorlooks like a function definition, but there is no formal parameter list.
error C2059: syntax error: '{'
it really looks like the compiler cant handle HLSL at all...maybe VS2012 express doesnt support HLSL?
thanks in advance
HLSL is not C++. You should compile shaders with shader compiler, and C++ with C++ compiler — do not mix. There are two options for compiling HLSL.
Use command-line utility fxc.exe that is included in DirectX SDK (docs and usage here at MSDN). It generates a file that you should load in runtime by some of the ways described here.
Compile your shader at runtime by using D3DCompileFromFile function.
There are pros and cons about each of the variants. In short, pre-compiling at build time gives you some time gain at runtime, while compiling at runtime is more flexible and comfortable at development stage (no need to remember to recompile it or to use post-build scripts) but is more error-prone. Choose by yourself.
The code looks fine for HLSL. If you want to compile it from within VS2012 set the ".fx" file to build using the HLSL shader compiler. Right click the file select properties. Then select General and Item Type should be set to HLSL compiler.
If you really want to make shaders using C++ you could look into C++AMP to see if it may suit your needs.
it really looks like the compiler cant handle HLSL at all...maybe VS2012 express doesnt support HLSL?
No C++ compiler does. It is not supposed to be handled by the compiler.
You need to turn it into a resource and copy it into the bin directory using post-build scripts, and load the HLSL at runtime.
See also: http://www.directxtutorial.com/Lesson.aspx?lessonid=11-4-5
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.
I am getting C++ Compiler error C2371 when I include a header file that itself includes odbcss.h. My project is set to MBCS.
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\odbcss.h(430) :
error C2371: 'WCHAR' : redefinition; different basic types 1>
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winnt.h(289) :
see declaration of 'WCHAR'
I don't see any defines in odbcss.h that I could set to avoid this. Has anyone else seen this?
This is a known bug - see the Microsoft Connect website:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98699
The error doesn't occur if you compile your app as Unicode instead of MBCS.
There are a half-dozen posts on various forums around the web about this - it seems to potentially be an issue when odbcss.h is used in the presence of MFC. Most of the answers involve changing the order of included headers (voodoo debugging). The header that includes odbcss.h compiles fine in it's native project, but when it is included in a different project, it gives this error. We even put it in the latter project's stdafx.h, right after the base include for MFC, and still no joy. We finally worked around it by moving it into a cpp file in the original project, which does not use MFC (which should have been done anyway - but it wasn't our code). So we've got a work-around, but no real solution.
This error happens when you redeclare a variable of the same name as a variable that has already been declared. Have you looked to see if odbcss.h has declared a variable you already have?
does this help?
http://bytes.com/forum/thread602063.html
Content from the thread:
Bruno van Dooren [MVP VC++] but i know the solution of this problem.
it solves by changing project setting of "Treat wchar_t as Built-in
Type" value "No (/Zc:wchar_t-)". But I am using "Xtreme Toolkit
Professional Edition" for making good look & Feel of an application,
when i fix the above problem by changing project settings a new
linking errors come from Xtreme Toolkit Library. So what i do to fix
this problem, in project setting "Treat wchar_t as Built-in Type"
value "yes" and i wrote following statements where i included wab.h
header file. You can change that setting on a per-codefile basis so
that only specific files are compiled with that particular setting. If
you can solve your problems that way it would be the cleanest
solution.
#define WIN16
#include "wab.h"
#undef WIN16
and after that my project is working fine and all the things related to WAB is also working fine. any one guide me, is that the right way
to solve this problem??? and, will this have any effect on the rest of
project?? I wouldn't worry about it. whatever the definition, it is a
16 bit variable in both cases. I agree that it isn't the best looking
solution, but it should work IF WIN16 has no other impact inside the
wab.h file.
--
Kind regards, Bruno van Dooren bruno_nos_pam_van_dooren#hotmail.com
Remove only "_nos_pam"