DirectX 11 and g++ compile error - c++

Hello I actually learning DirectX 11 with this tutorial: http://www.rastertek.com/dx11tut03.html
First Part
My code (where the probleme come from):
d3dclass.h:
//Linking
#pragma comment(lib, "dxgi.lib")
#pragma comment(lib, "d3d11.lib")
#pragma comment(lib, "d3dx11.lib")
#pragma comment(lib, "d3dx10.lib")
//Include
#include <dxgi.h>
#include <d3dcommon.h>
#include <d3d11.h>
#include <d3dx10math.h>
I do all like the tutorial, the only diference is I compile it with g++, trough this the command :
g++ -mwindows WinMain.cpp systemclass.cpp inputclass.cpp graphicsclass.cpp d3dclass.cpp -o Prog.exe -I "D:\Programme File\DirectX SDK\Include" 2> log.txt
but in the output file, I have a large sum of errors. This is the log.txt:
https://drive.google.com/open?id=1XUlcAFUyRcLIvdKbe0FkLVjkvwxpOmEv
To sum up the log there is a lot of things like __in which has not been declared in the dxgi.h, but this header is from DirectX11 Library;
Second Part
I found the way to fix a lot of my problem (of the first part) with adding this :
#define __in
#define __out
#define __inout
#define __in_bcount(x)
#define __out_bcount(x)
#define __in_ecount(x)
#define __out_ecount(x)
#define __in_ecount_opt(x)
#define __out_ecount_opt(x)
#define __in_bcount_opt(x)
#define __out_bcount_opt(x)
#define __in_opt
#define __inout_opt
#define __out_opt
#define __out_ecount_part_opt(x,y)
#define __deref_out
#define __deref_out_opt
#define __RPC__deref_out
but there still is a major problem, this is the error output :
D:\Programme File\DirectX SDK\Include/d3dx10core.h:345:13: error: expected ';' at end of member declaration
HRESULT WINAPI_INLINE GetDesc(D3DX10_FONT_DESCA *pDesc) { return GetDescA(pDesc); }
it comes from WINAPI_INLINE (this is in the DirectX header)
How can I fix this? please.

I don't have any experience with using g++, but I can help with a few details here. To use g++ you need to install the Windows SDK and configure it to include the proper paths. The legacy DirectX SDK requires the Windows SDK and is not fully standalone.
Note that the legacy DirectX SDK and the Windows SDK don't claim to be compatible with the GCC toolchain.
The __in, __out, etc. macros are called "SAL annotations" and they are there to improve the quality of static code analysis both internally at Microsoft and when using Visual C++'s /analyze switch. They are defined as 'blank' in other cases so they just get removed from the code. The macros are defined in the Windows SDK. You can try explicitly doing a #include <sal.h> and/or #include <specstrings.h> before including a version of dxgi.h.
Another thing to keep in mind is that the legacy DirectX SDK itself is deprecated along with the D3DX9, D3DX10, and D3DX1 utility libraries. As such, if you are using the Windows 8.0, 8.1, or 10 SDK you can code Direct3D 11 without using it at all--see Living without D3DX. If you do want to continue to use those older helpers--which the somewhat dated rastertek tutorials assume--, you can do so but you need to make sure the DirectX SDK include and lib paths are searched after the Windows SDK include/lib paths.
If you were using Visual C++ (which BTW has a free Community edition available), then you'd probably be having an easier time. You might also want to see the DirectX Tool Kit tutorials.

Related

ShGetKnownFolderPath not working C++ [duplicate]

(Visual Studio 2010 / Visual C++ / Windows 7)
example.cpp:
#include <Shlobj.h>
#pragma comment (lib, "Shell32.lib")
...
void example()
{
SHGetKnownFolderPath(...) // undefined
}
I'm doing everything according to documentation and what I see in other threads, but it still doesn't work.
I had exactly the same problem. Another project with the same code and ancillary files (but different includes) was working.
Putting #include <Shlobj.h> at the top of the file solved the problem.
It might not be replicable though, as it should have worked without doing that. Probably another Visual Studio bug.
Try putting following statement before all includes:
#define WINVER 0x0600
#define _WIN32_WINNT 0x0600
Since the documentation says it needs Vista/2008 minimum.

TBB on Windows XP (using in OpenCV) - error entry point InitializeCriticalSectionEx

I tried to compile TBB which I want to use on OpenCV. I am using Windows XP and Visual Studio 2010 C++. When I compiled TBB 4.4 I got the error
"The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll."
The error is similar but under little different conditions like here:
http://answers.opencv.org/question/6151/opencv_createsamplesexe-entry-point-problem-with-xp/
In my case I cannot run the program at all. I tried the solution described there, so I renamed InitializeCriticalSectionEx to InitializeCriticalSection and removed parameter 2 and 3.
OpenCV claimes the bug is not on their side. I know OpenCV uses this:
#if (_WIN32_WINNT >= 0x0600)
InitializeCriticalSectionEx(&cs, 1000, 0);
#else
InitializeCriticalSection(&cs);
#endif
I know this should not make any problems but I commented some lines to keep InitializeCriticalSection(&cs); only. I recompiled the OpenCV and still the same error. Finally I have found in TTB:
tbb44_20160627oss\include\tbb\machine\windows_api.h
__TBB_WINBASEAPI BOOL WINAPI TryEnterCriticalSection( LPCRITICAL_SECTION );
__TBB_WINBASEAPI BOOL WINAPI InitializeCriticalSectionAndSpinCount( LPCRITICAL_SECTION, DWORD );
// Overloading WINBASEAPI macro and using local functions missing in Windows XP/2003
#define InitializeCriticalSectionEx inlineInitializeCriticalSectionEx
I also find the word "InitializeCriticalSectionEx" in opencv_core310d.dll and opencv_core310.dll. Does the overload really work and why I got the error? How could I fix it?
Update:
the definition in OpenCV
#ifndef _WIN32_WINNT // This is needed for the declaration of TryEnterCriticalSection in winbase.h with Visual Studio 2005 (and older?)
#define _WIN32_WINNT 0x0400 // http://msdn.microsoft.com/en-us/library/ms686857(VS.85).aspx
#endif
"The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll."
This is a standard error that Windows displays when you try to run a program that contains a statically-bound call to a function in a DLL that does not exist.
The InitializeCriticalSectionEx function is not available on Windows XP, but the version of the library that you have contains code that calls this function.
OpenCV claimes the bug is not on their side. I know OpenCV uses this:
#if (_WIN32_WINNT >= 0x0600)
InitializeCriticalSectionEx(&cs, 1000, 0);
#else
InitializeCriticalSection(&cs);
#endif
OpenCV's workaround is a compile-time solution. It determines at the point when the library is compiled which version of Windows is being targeted, and uses that information to generate a call to the appropriate version of the function.
There are two possibilities for why this is going wrong in your case:
You are using the OpenCV library in binary form, and the binary that you have was compiled to target Windows Vista and later. You can solve this by obtaining the source code for OpenCV and compiling it yourself, either as a DLL or a static library.
You are compiling with _WIN32_WINNT set to 0x0600 or later. By default, the Windows headers define this symbol to the latest available version. You have to explicitly define an earlier target version if you want it. To arrange for targeting Windows XP, add the following code at the top of your code file (probably in your precompiled header):
#include <WinSDKVer.h>
#define _WIN32_WINNT _WIN32_WINNT_WINXP
#include <SDKDDKVer.h>

How to turn on GDI+ 1.1 instead of 1.0 in MFC project?

I unable to use GDI+ 1.1 classes in my VS2012 MFC C++ project (on Win7). Classes Image, Bitmap, Graphics works just fine but when I try to declare an object of Blur class (or other v1.1 classes) I am getting an error C2065: ‘Blur’: undeclared identifier. I tried to define GDIPVER (in stdafx.h) like this
#define GDIPVER 0x0110 //also I get the warning C4005: 'GDIPVER' : macro redefinition
#include <gdiplus.h>
#pragma comment (lib,"Gdiplus.lib")
but it does not work.
How to turn on GDI+ 1.1 instead of 1.0?
I fought with a similar issue for a while on one project. For me, my precompiled header has this:
#define GDIPVER 0x0110 // Use more advanced GDI+ features
but the precompiled header does not #include "gdiplus.h". That only occurs in the .cpp files which actually make GDI+ calls. I forward declare GDI+ classes for the headers which have GDI+ object pointers as members. As Hans and other comments noted, there's probably another header including gdiplus.h before the GDIPVER is set. To figure out where it's included try going to the C/C++ > Command Line settings for your project and add /showIncludes then do a full build and look in the build log for gdiplus.h and track back to the first header including it.
Once you clear that hurdle, I also discovered my application would not actually use the 1.1 features unless the manifest was also updated. So one of my .cpp files has this:
// Update Manifest
// cf: http://blogs.msdn.com/b/oldnewthing/archive/2007/05/31/2995284.aspx
//
// We use features from GDI+ v1.1 which is new as of Windows Vista. There is no redistributable for Windows XP.
// This adds information to the .exe manifest to force GDI+ 1.1 version of gdiplus.dll to be loaded on Vista
// without this, Vista defaults to loading version 1.0 and our application will fail to launch with missing entry points.
#if 64BIT_BUILD
#pragma comment(linker, "\"/manifestdependency:type='Win32' name='Microsoft.Windows.GdiPlus' version='1.1.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#else
#pragma comment(linker, "\"/manifestdependency:type='Win32' name='Microsoft.Windows.GdiPlus' version='1.1.0.0' processorArchitecture='X86' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif
FWIW, I did the following to enable GDI+ 1.1 in a VS 2019 MFC project:
Added this line in pch.cpp before including pch.h:#define GDIPVER 0x0110
Added these lines in pch.h after including framework.h:#include <gdiplus.h>using namespace Gdiplus;
Used a slightly modified and updated version of the code block kindly provided by #jschroedl 7 (!) years ago:
// Update Manifest
// cf: http://blogs.msdn.com/b/oldnewthing/archive/2007/05/31/2995284.aspx
//
// We use features from GDI+ v1.1 which was new as of Windows Vista. There is no redistributable for Windows XP.
// This adds information to the .exe manifest to force the GDI+ 1.1 version of gdiplus.dll to be loaded.
// Without this, Windows will load the GDI+ 1.0 version of gdiplus.dll and the application will fail to launch with missing entry points.
#ifdef _WIN64
//#pragma comment(linker, "\"/manifestdependency:type='Win32' name='Microsoft.Windows.GdiPlus' version='1.1.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#else
//#pragma comment(linker, "\"/manifestdependency:type='Win32' name='Microsoft.Windows.GdiPlus' version='1.1.0.0' processorArchitecture='X86' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif
I instantiated a Blur object in my startup code to verify I was compiling against GDI+ 1.1 and scoping it so it would be destroyed before calling GdiplusShutdown(), and the app ran and shut down correctly in both x86 and x64 builds.

Automatically Including OpenCV Libraries of Different Versions

I've been automatically including the opencv library files for my c++ code on Visual Studio 2008 on Windows 7 with the following code:
#ifndef NDEBUG
#pragma comment(lib, "opencv_core231d.lib")
#pragma comment(lib, "opencv_highgui231d.lib")
#pragma comment(lib, "opencv_imgproc231d.lib")
#else
#pragma comment(lib, "opencv_core231.lib")
#pragma comment(lib, "opencv_highgui231.lib")
#pragma comment(lib, "opencv_imgproc231.lib")
#endif
but I run into trouble when the system has a different version of the opencv library installed because the .lib files have the version (in this case, 2.31) in the filename. Is there a good way to automatically or near-automatically detect what version of the opencv library is available then slide in the appropriate version string into the pragma?
There are small changes between different OpenCV versions - not much, but enough to crash your app when you change from 2.0 to 2.2 or from 2.2 to 2.3.1. Also, the beta 2.4 release has enough changes from previous ones.
So best is to test your app with an OpenCV version, and deliver it with those dlls only.
A small example:
Mat a(3,3,CV_8UC3);
a.setTo( Scalar(10) ); // in 2.3.1 will set all channels to 10,
// in 2.2 will only set first channel.
The corresponding 2.2 call would be
a.setTo(Scalar::all(10));
Or
a = 0; // runs fine on 2.3.1. Equivalent to setTo().
// Does not compile on earlier versions
Another example is cv::drawPoly(), which has a different signature on 2.2 and 2.3.1.
Given the fact that those changes are not well documented, the chance to miss one of them by mistake is really high.
I have worked out a solution to having code run on various versions of OPENCV by merging the following articles:
How to make a string out of macros
Concatenating strings in macros
Pragma statements in #defines with support for VS2008 here on MSDN
Bonus: How to have global settings defined in a solution
As noted, this can cause some serious grief if you pop between incompatible versions but for those versions and features supported this may be useful to some. Use this technique to set the opencv version once and have your code automatically link to the desired version by either
define the OPENCV_VERSIONin one place in your source code
Define it in a Property Sheet
Define it in a system environment variable.
My code ended up like so:
#include <iostream>
// #define OPENCV_VERSION $(OPENCV_VERSION)
// #define OPENCV_VERSION 220
#define QUOTE(name) #name
#define STR(macro) QUOTE(macro)
#define LINK_TO_OPENCV(libname) __pragma(comment(lib, "opencv_" #libname STR(OPENCV_VERSION)))
#define LINK_TO_OPENCV_DEBUG(libname) __pragma(comment(lib, "opencv_" #libname STR(OPENCV_VERSION) "d"))
#ifndef NDEBUG
LINK_TO_OPENCV_DEBUG("core")
LINK_TO_OPENCV_DEBUG("highgui")
LINK_TO_OPENCV_DEBUG("imgproc")
#else
LINK_TO_OPENCV("core")
LINK_TO_OPENCV("highgui")
LINK_TO_OPENCV("imgproc")
#endif
int main()
{
std::cout << STR(LINK_TO_OPENCV("core")) << "\n";
return 0;
}
And now to set the OPENCV_VERSION anywhere you like. For example, you can have a single header file included by everyone that has the line:
#define OPENCV_VERSION 220
Or you can goto Project->Properties->C/C++->Preprocessor and set Preprocessor Definitions to OPENCV_VERSION=220. Or you can do the same thing in a shared property sheet for the entire solution.
Or, and this is important, you can use this technique to define a global environment variable in windows itself called OPENCV_VERSION_ENV and set its value to the version code (say, 220). Then you can put set the preprocessor definition to OPENCV_VERSION=$(OPENCV_VERSION_ENV) and you will bring in the environment variable into the link command. You CANNOT do a #define OPEN_VERSION $(OPENCV_VERSION_ENV) but since the property pages will automatically translate $(macros) we can get environment variables there.

Can't Include winhttp.h (with code::blocks/mingw) c++

I've been trying to include winhttp.h and I get this error:
Winhttp.h: No such file or directory
Mingw doesn't have it, how would I add it?
You can use runtime dynamic linking to link to the function(s) you want directly. You can't use the plain winhttp.h that ships with the Windows SDK because it contains Microsoft-specific features. You could also compile with Visual C++ 2010 Express Edition which would include the header you want.
Hope that helps :)
I have copied the header from windows and it worked fine with the following addition:
#define __in
#define __out
#define __out_bcount(x)
#define __in_ecount(x)
#define __inout
#define __out_ecount_full_opt(x)
#define __in_opt
#define __out_data_source(x)
#include <winhttp.h>
hope this helps.
GET: https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/app/org.eclipse.higgins.tcpserver/src/Third-party/VS2008/winhttp.h
dlltool -z winhttp.def --export-all-symbol winhttp.dll
dlltool -k -d winhttp.def -l libwinhttp.a
Link against the libwinhttp.a you just generated.