Atlbase won't include properly in Unreal Engine 4 - c++

I'm using the full version of VS2013, and am trying to include atlbase into a class, along with sphelper, but I'm getting various types of errors.
I'm using a newly generated class, which will cleanly compile without these inclusions, and has pretty much nothing else inside of it.
The compiler is finding the libraries and seems to load them, but then I get around 20 errors that are all pretty much just like this (I omitted the rest, but they are all just like these ones)
1>E:\Programs\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE\atlcore.h(630): warning C4191: 'reinterpret_cast' : unsafe conversion from 'FARPROC' to 'BOOL (__cdecl *)(DWORD)'
1> Calling this function through the result pointer may cause your program to fail
1>E:\Programs\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE\atltransactionmanager.h(271): warning C4191: 'type cast' : unsafe conversion from 'FARPROC' to 'PFNCREATETRANSACTION'
1> Calling this function through the result pointer may cause your program to fail
1>E:\Programs\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE\atltransactionmanager.h(321): warning C4191: 'type cast' : unsafe conversion from 'FARPROC' to 'PFNCOMMITTRANSACTION'
1> Calling this function through the result pointer may cause your program to fail
1>E:\Programs\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE\atltransactionmanager.h(427): error C2039: 'DeleteFile' : is not a member of '`global namespace''
1>E:\Programs\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE\atltransactionmanager.h(448): warning C4191: 'type cast' : unsafe conversion from 'FARPROC' to 'PFNMOVEFILETRANSACTED'
1> Calling this function through the result pointer may cause your program to fail
1>E:\Programs\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE\atltransactionmanager.h(460): error C2039: 'MoveFile' : is not a member of '`global namespace''
1>E:\Programs\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE\atltransactionmanager.h(487): warning C4191: 'type cast' : unsafe conversion from 'FARPROC' to 'PFNGETFILEATTRIBUTESTRANSACTED'
1>E:\Programs\Microsoft Visual Studio 12.0\VC\ATLMFC\INCLUDE\atlbase.h(5766): warning C4191: 'type cast' : unsafe conversion from 'FARPROC' to 'LSTATUS (__cdecl *)(HKEY,LPCWSTR,REGSAM,DWORD)'
1> Calling this function through the result pointer may cause your program to fail
1>C:\Program Files (x86)\Windows Kits\8.1\include\um\sphelper.h(1333): warning C4191: 'type cast' : unsafe conversion from 'FARPROC' to 'LPFN_RegLoadMUIStringW'
1> Calling this function through the result pointer may cause your program to fail
These errors present themselves only after atlbase.h and/or sphelper.h are included. Half of them from the first, the other half from the second.
They are included as follows (beneath my project and class header inclusion):
#include <stdio.h>
#include <Windows.h>
#include "AllowWindowsPlatformTypes.h"
#include <atlbase.h>
#include "sphelper.h"
#include "HideWindowsPlatformTypes.h"
I have them within this 'platform types' block because the atlbase and sphelper libraries throw an obscene amount of errors each otherwise, pertaining to arbitrary declarations or something.
I have not edited the library files in any way, and completely deleted all of the libraries and reinstalled them from scratch.
It may be due to an oversight or something on my part, but can anyone explain why the atl and sphelper libraries won't include properly?
Edit:
To clarify, the solution to the problem in which I "resolved" that led to this problem, I found on "https://answers.unrealengine.com/questions/27560/trouble-using-windows-includes-with-dword-int.html"

I posted my problem on a more specific site, and got an answer there.
User Jamie Dale posted the following on UE4 AnswerHub
#include "AllowWindowsPlatformTypes.h"
#pragma warning(push)
#pragma warning(disable: 4191) // warning C4191: 'type cast' : unsafe conversion
#pragma warning(disable: 4996) // error C4996: 'GetVersionEx': was declared deprecated
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
// atltransactionmanager.h doesn't use the W equivalent functions, use this workaround
#ifndef DeleteFile
#define DeleteFile DeleteFileW
#endif
#ifndef MoveFile
#define MoveFile MoveFileW
#endif
#include <atlbase.h>
#undef DeleteFile
#undef MoveFile
#include <sphelper.h>
#pragma warning(pop)
#include "HideWindowsPlatformTypes.h"
This work around replaces the inclusions I used, and completely solved all of the problems I had. Full credit towards Jamie Dale on there.

Related

Resurrecting Visual C++ 9.0 application

I've been handed an ancient C++ application and asked to see if I can get it building and running again. I first tried building it using Visual Studio 2022 and ran into a lot of problems, so thought I would try building it in the environment it was used to.
The VCPROJ starts with this:
<VisualStudioProject
ProjectType="Visual C++"
Version="9.00"
Name="FsxApp"
ProjectGUID="{D0B8B3A6-3037-46F2-93D2-40318F591EEE}"
RootNamespace="FsxApp"
Keyword="MFCProj"
TargetFrameworkVersion="131072"
>
Looking up Visual C++ 9.0 in wikipedia, it says that version maps to "Visual Studio 2008 9.0" so I installed Visual Studio 2008. For some reason, Visual Studio can't find the files that are right in front of it so I had to add $(ProjectDir) to the "Additional Include Directories".
Now, VS complains because it can't find afxwin.h so I added the path of my modern MFC folder, and then it couldn't find winsdkver.h and winapifamily.h, and I found those in subfolders of a folder titled "Windows Kits" that I added to the list.
And now it's complaining because
#if (WINVER < 0x0501)
#error MFC does not support WINVER less than 0x0501. Please change the definition of WINVER in your project properties or precompiled header.
#endif
and sure enough, my stdafx.h says
#ifndef WINVER // Allow use of features specific to Windows 95 and Windows NT 4 or later.
#define WINVER 0x0500 // Windows 2000 or later. (Necessary to use GetTitleBarInfo())
#endif
#ifndef _WIN32_WINNT // Allow use of features specific to Windows NT 4 or later.
#define _WIN32_WINNT 0x0500 // Windows 2000 or later.
#endif
#ifndef _WIN32_WINDOWS // Allow use of features specific to Windows 98 or later.
#define _WIN32_WINDOWS 0x0500 // Windows 2000 or later.
#endif
and if I change all of those to 0x0501, it is very unhappy:
winnt.h(7063) : warning C4163: '_InterlockedExchangeAdd8' : not available as an intrinsic function
winnt.h(7349) : warning C4163: '__cpuidex' : not available as an intrinsic function
atltrace.h(92) : error C2065: 'nullptr' : undeclared identifier
atlwinverapi.h(714) : error C2159: more than one storage class specified
atlwinverapi.h(714) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
atlwinverapi.h(714) : error C2440: 'initializing' : cannot convert from 'PFNLCMAPSTRINGEX' to 'volatile int'
atlwinverapi.h(714) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
atlwinverapi.h(714) : error C2440: 'initializing' : cannot convert from 'PFNLCMAPSTRINGEX' to 'int'
atlwinverapi.h(714) : error C2446: '==' : no conversion from 'PFNLCMAPSTRINGEX' to 'int'
atlwinverapi.h(714) : error C2040: '==' : 'int' differs in levels of indirection from 'PFNLCMAPSTRINGEX'
atlwinverapi.h(714) : error C2440: '=' : cannot convert from 'PFNLCMAPSTRINGEX' to 'int'
atlwinverapi.h(714) : error C2440: '=' : cannot convert from 'PFNLCMAPSTRINGEX' to 'volatile int'
atlwinverapi.h(714) : error C2440: '=' : cannot convert from 'PFNLCMAPSTRINGEX' to 'int'
atlwinverapi.h(714) : error C2446: '!=' : no conversion from 'PFNLCMAPSTRINGEX' to 'int'
atlwinverapi.h(714) : error C2040: '!=' : 'int' differs in levels of indirection from 'PFNLCMAPSTRINGEX'
atlwinverapi.h(716) : error C2100: illegal indirection
atlwinverapi.h(716) : error C2064: term does not evaluate to a function taking 9 arguments
atlcore.h(37) : fatal error C1083: Cannot open include file: 'type_traits': No such file or directory
which isn't surprising at all, when one grabs random include folders.
So then I wondered if I could find the correct version of MFC. According to wikipedia, the MFC in use during Visual Studio 2008 was mfc90.dll but if you google "download mfc90.dll" you get a bunch of questionable links, and those that look semi-possible just have the DLLS, not the H files.
Is finding an old version of MFC my best bet? Is there some other way to get an old application building?

GDI+ library causes "error C2760: syntax error: unexpected token 'identifier', expected 'type specifier'" in VS2017 when compiled for XP

I'm trying to include the following definitions for GDI+ into my Win32 C++ project that is compiled under Visual Studio 2017:
#include <objidl.h>
#include <gdiplus.h>
#pragma comment (lib,"Gdiplus.lib")
I need to compile this project to support Windows XP. So in the project properies I selected: Platform Toolset as Visual Studio 2017 - Windows XP (v141_xp):
But when I compile it the GDI+ library gives me this:
1>c:\program files (x86)\microsoft sdks\windows\v7.1a\include\objbase.h(239): error C2760: syntax error: unexpected token 'identifier', expected 'type specifier'
1>c:\program files (x86)\microsoft sdks\windows\v7.1a\include\gdiplusheaders.h(891): error C4596: 'EmfToWmfBits': illegal qualified name in member declaration
1>c:\program files (x86)\microsoft sdks\windows\v7.1a\include\gdiplusstringformat.h(220): error C4596: 'GetTrimming': illegal qualified name in member declaration
Any idea how to fix this?
Add this line before the very first(!) #include of COM-related header to fix objbase.h(239): error C2760: syntax error: unexpected token 'identifier', expected 'type specifier' :
typedef struct IUnknown IUnknown;
This fix works, because the line in objbase.h(239) mentioned in the error contains static_cast<IUnknown*>(*pp); despite that IUnknown still haven't been declared in that place.
I kinda got it to compile, but this is definitely not a good solution. I'm posting it here as a temp workaround until Microsoft gets their heads out of their ___es. Also if anyone finds a better way, please let me know.
I basically had to downgrade the entire project to Visual Studio 2015 - Windows XP (v140_xp) just to compile one badly written library:
This created a problem of its own with the std libraries:
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cstdio(50): error C4995: 'sprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cstdio(53): error C4995: 'vsprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cstring(20): error C4995: 'strcat': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cstring(21): error C4995: 'strcpy': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cwchar(29): error C4995: 'swprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cwchar(30): error C4995: 'vswprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cwchar(32): error C4995: 'wcscat': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\cwchar(34): error C4995: 'wcscpy': name was marked as #pragma deprecated
So I had to shunt those errors of unsafe functions:
#pragma warning( push )
#pragma warning( disable: 4995 )
#include <stdio.h>
#include <new>
#include <string>
#pragma warning( pop )
Which is far from ideal!
(You're basically sacrificing security of the app just to compile that damn GDI+ library.)
There's a way to get this to work if you're prepared to edit the Windows header files.
In objbase.h, comment out line 239 or change it to:
static_assert (std::is_base_of <IUnknown *, *pp>::value, "pp must derive from IUnknown");
In gdiplusheaders.h, line 891, remove the redundant qualifier (Metafile::).
In gdiplusstringformat.h, line 220, remove the redundant qualifier (StringFormat::).
Hopefully, that will fix things for you without breaking anything.
Although the question is old, just adding what worked for me.
In my case including windows.h and compiling with VS2017 v141_xp toolset was causing me error: syntax error: unexpected token 'identifier', expected 'type specifier'.
This resolved my issue link

Compile errors when including std::mutex before jemalloc.h

This
//CSocket.h
#ifndef __SERVER_CSOCKET_H__
#define __SERVER_CSOCKET_H__
#include "winsock2.h"
#include "ws2tcpip.h"
#include <thread>
#include <stdio.h>
#include <string>
(cpp includes only the header)
//CSocket.cpp
#include "CSocket.h"
produces the following error messages in c:\program files (x86)\microsoft visual studio 12.0\vc\include\ratio
ratio(122): error C2065: 'INTMAX_MAX': undeclared identifier
ratio(133): See reference to the instance of the just compiled class-template "std::ratio<_Nx,_Dx>".
ratio(124): error C2065: 'INTMAX_MAX': undeclared identifier
ratio(44): error C2065: 'INTMAX_MAX': undeclared identifier
ratio(217): See reference to the instance of the just compiled class-template "std::_Safe_mult<0x01,0x01>".
ratio(36): error C2338: integer arithmetic overflow
ratio(44): See reference to the instance of the just compiled class-template "std::_Safe_multX<0x01,0x01,false>".
ratio(44): error C2039: 'value': Is not an element of 'std::_Safe_multX<0x01,0x01,false>'
ratio(44): error C2065: 'value': undeclared identifier
ratio(44): error C2057: Expected constant expression
ratio(44): error C2039: 'value': Is not an element of 'std::_Safe_multX<0x01,0x0989680,false>'
ratio(219): error C2975: "_Nx": invalid template argument for "std::ratio", expected compile-time constant expression.
ratio(116): See declaration of '_Nx'
ratio(219): error C2975: "_Dx": invalid template argument for "std::ratio", expected compile-time constant expression.
ratio(117): See declaration of '_Dx'
CSocket.cpp
Including std::thread in the .cpp and not in the header solves all errors but I don't know why it doesn't work in the header.
//CSocket.cpp
#include "CSocket.h"
#include <thread>
The only library I am using is jemalloc.
Might the error come from including jemalloc.h before mutex not from thread itself?
I had to #include <mutex> before #include "jemalloc.h" and not afterwards.
Works fine now, strange errors though.
I am having the same error, but the order of the includes is not useful for me. I think this has something to do with other includes that also use chrono and thread, so you can checkout that.
Are you using Visual Studio? Seems like more people is getting the same error: https://connect.microsoft.com/VisualStudio/feedback/details/800726/compiler-error
I have the same errors with VS2013 update 3. The problem seems to be the fact that INTMAX_MAX is not defined, but it is used in ratio.h.
My solution is to add
#define INTMAX_MAX INT64_MAX
before #include <ratio> in your file (if you do not have the line, you may add it).
The line to be included can be found in stdint.h - in your case, the right side can be different.
PS Another solution is to #include <stdint.h> and to define __STDC_LIMIT_MACROS. In this case, you may get some warnings about duplicate macros.
it occurs to the project when i use the CxImage as third party library and with threadpool in C++11. Separately they are all okay, while merged in the same project, that errors occur.
the solution is add the precompile option of _STDC_LIMIT_MACROS to
Property Pages -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions of the Project.
PS: my environment is : MFC/VS2015 && windows7 64bit
may it be helpful to somebody :)

Fix macro redefinition in C++

Since intsafe.h and stdint.h both define INT8_MIN. Thus VS2010 generate a warning that says :
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdint.h(72): warning C4005: 'INT8_MIN' : macro redefinition
1> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\intsafe.h(144) : see previous definition of 'INT8_MIN'
Is there a way to fix that warning in VS2010.
Apparently it's a bug in VS2010. You can avoid it in general but in MFC applications it's basically impossible to ever include stdint.h in any of your other code without hitting it.
I just did this at the top of the file that was complaining:
#pragma warning (push)
#pragma warning (disable : 4005)
#include <intsafe.h>
#include <stdint.h>
#pragma warning (pop)
It gets those headers 'out of the way' so to speak and lets you get on with your day.
In order simply to make the message go away, you can add the line
#pragma warning (disable : 4005)
before your first #include statement
But that doesn't mean you shouldn't heed the warning. See if you can do without one of the two header files, and if not, be very certain of which definition your program is using.

VC++ 2008 compiling problem with boost

All of a sudden a two project solution started to fail to compile. I don't remember making any change that could compromise the build. One project is a lib and the other is exe. The lib is still compiling without issues, but the exe fails. I isolated the issue at a point when some boost files are loaded. Here is a the stdafx.cpp that is enough to show the error:
#include "stdafx.h"
#include <boost/thread.hpp>
And these are the errors reported:
1>Compiling...
1>stdafx.cpp
1> c:\program files (x86)\microsoft visual studio 9.0\vc\include\stdlib.h(525) : see declaration of '_ultoa'
1>c:\libs\boost_1_44_0\boost\mpl\size_t_fwd.hpp(23) : error C2143: syntax error : missing ',' before 'constant'
1>c:\libs\boost_1_44_0\boost\mpl\aux_\integral_wrapper.hpp(42) : error C2143: syntax error : missing ',' before 'constant'
1>c:\libs\boost_1_44_0\boost\mpl\aux_\integral_wrapper.hpp(84) : error C2143: syntax error : missing ',' before 'constant'
1>c:\libs\boost_1_44_0\boost\mpl\aux_\integral_wrapper.hpp(84) : error C3211: 'boost::mpl::size_t<__formal>::value' : explicit specialization is using partial specialization syntax, use template <> instead
1> with
1> [
1> __formal=1135
1> ]
1> c:\libs\boost_1_44_0\boost\mpl\aux_\integral_wrapper.hpp(45) : see declaration of 'boost::mpl::size_t<__formal>::value'
1> with
1> [
1> __formal=1135
1> ]
I noticed that if I change the include line to:
#include "stdafx.h"
#include <boost/thread/thread.hpp>
it works, but then I have other includes in the code as:
#include <boost/bind.hpp>
#include <boost/function.hpp>
and they also give the same 4 error lines.
Anyone have any idea what could be wrong? I am restating that this code worked for months and the error first came yesterday.
Hard to guess, but I think there might be some macro defined in stdafx.h that collides with Boost (i.e. Boost uses a variable/function/template/whatever with the same name as your macro). Remember that macros span over scopes. A quick check - does the problem vanish if you change the order of includes?