I’m trying to build a plugin, that will use <WinSock2.h>
I can include the standard UE4 engine headers fine, but then I have to include winsock2.h.
To avoid the “ambiguous symbol” for DWORD and such, I have to do this:
I ‘assume’ PF_MAX is a define. Perhaps you could try simply using #undef PF_MAX before the winsock include? Not sure it would work, I stay away from the preprocessor as much as possible.
No, that’s not the right solution. There are more compile errors; that’s the first one; I posted it mainly as an indication that, clearly, something’s wrong here.
If I were to modify anything, it would be to insert #include <WinSock2.h> right after the include for <Windows.h> in the Unreal platform headers; that has the least chance of breaking (but it probably will still break.)
Although, yes, PF_MAX is defined as a pixel format in the Unreal headers. But it’s also a … protocol family enum? … in the Windows headers.
If I try to include winsock2.h ahead of the engine, then the engine attempt to minify windows headers don’t work, and I get a bunch of symbol errors on, IIRC, atomic intrinsics.
I think this is a bug. The “allowwindowsplatformtypes.h” header doesn’t seem to work right, and/or the Unreal namespace doesn’t play cleanly with Windows headers. I’m surprised nobody else has run into it, though.
Btw: There may exist a really painful work-around, which would be for each of my Unreal classes to call to a separate implementation (possibly through some C callable interface) and have that implementation not include Unreal headers at all, just Windows. And then figuring out how to make the Unreal tools generate a nmake file that doesn’t use the Unreal precompiled header for that implementation…
Well, the cause of the problem and a possible workaround are now on answerhub:
Presumably this will be added to the bug db at some point?
Suggestion: Change the “PF_” constants to something more Unreal Engine-specific in PixelFormats.h. (UEPF_… ?)