Constant Library Conflicts

Development Programming & Scripting
1

There is a plague in the unreal code base known as macros. You guys name them with commonplace words like “check” (the most frequent offender in my experience) and that’s a problem. There are documented issues with HUGELY popular libraries not the least of which includes OpenCV and Boost, they have objects named “check”. Having a macro named “check” means that as a preprocessor directive, it overwrites library header files mentioning of “check”, namespaces do not weigh in. What needs to be done is either renaming your macros such that they won’t conflict so often (eg prefixing), OR reimplement the macros using templates which obey namespace rules.

2

Hello ,

As we don’t support those extra libraries, we most likely won’t be making any direct changes to the source code to change this at this time. However, I would suggest looking at AllowWindowsPlatformTypes.h and HideWindowsPlatformTypes.h and how they are handling the macros defined there. This should be able to give you an idea of how to incorporate the Boost library’s macros that are conflicting.

3

, thanks very much for providing a prospective answer, but I don’t appreciate you marking it as THE answer, because I wouldn’t accept this as an answer.

That you don’t support a third party library goes without saying, but I don’t think it’s asking too much to ask that epic should be making code that is in following with C++ standards. The Boost Library doesn’t use such commonplace named macros. Unreal’s macros are conflicting with boost function names. Unreal macros are conflicting with popular libraries’ symbol names, which is causing confusion among many developers in the unreal community, as to why they can’t use a given library with unreal, and the errors they get don’t necessarily tell them that the problem is an unreal macro screwing up the library’s code. If you have a macro called “check” and someone wants to make a function called “check” that causes a very difficult to debug conflict. These are problems that should be addressed, not just shrugged off. I shouldn’t be expected to modify Boost to work with unreal, I should expect Unreal not conflict with C++ standards. Boost being written by the same people who write the STL, and many modules of Boost being incorporated to the STL, of all libraries you SHOULD avoid conflicting with, STL and Boost are at the top of that list.

4

Please be aware that the answer being marked as accepted is an automatic thing from answerhub that happens when staff members post an answer, mainly for tracking reasons.

I understand your stance in this matter. Due to that, I’ll enter a feature request to have these macros changed. Please understand however, that it may not happen not solely due to how we use these macros, but how all of our users have been using them as well. I’ll be sure to update you on the status of the request whenever its updated.

In the meantime, could you give a list of all of the conflicting macros that you’ve encountered, other than “check”? This is to ensure that we don’t miss any if we do decide to make these changes.

5

At present it is a problem I’ve only run into concerning check. It seems that I and many who have attempted to use OpenCV have run into the check macro collision, I’ve seen more than a couple people run into the issue post about it and never get a solution, presumably they deserted their efforts. I’m running into it again trying to work with Boost, so check collision is 2 for 2. I am relatively new to Unreal, so it strikes me as funny that Unreal may have such a collision with EVERY library that has any object that has a method “check” somewhere declared in it’s header files. This is probably because a defined macro check is LEAKING. One solution would be to rename macros, but another would be to undefine macros where they shouldn’t be applied…

6

Thank you for the information. If you do find any other macros that cause conflicts, please let me know and I’ll have them added to the report but in the meantime, the feature request is in and waiting to be reviewed.

Have a nice day!

7

Boost is a very ubiquitous library and many libraries and concepts in it makes into the c++ standard. whatever your stance on third party libraries using lower case common words for macro names (check,verify etc) is a very bad practice
and I should not need jumble pragmas to undef the stuff…

8

I want to weigh in on this request to resolve the macro name collision to allow the use of Boost within UE4.

I have written a driver to interface with a custom controller that requires Boost. After days of work I now get to the point where I want to expose the device in Unreal and I make the shocking realization that because of this issue the integration won’t work… You can imagine that I am slightly upset by the situation (to say the least).

At this stage the compiler only throws errors about macro ‘check’.

Please, please, please fix this issue.

In the meantime, is there a workaround?

9

Hello jeancf,

The feature request for this is still in our system and still open. You can find that feature request here: UE-28766. This change would be a large undertaking and, as mentioned previously, would affect every user who has ever used a check in their own project or in their own engine edit. There is not a workaround that I’m aware of at this time.

10

Obviously I don’t like the answer but there is nothing more I can do about it.
May I suggest to add a note somewhere in the development sections of the documentation highlighting the incompatibility with these popular libraries? Just to avoid that somebody else wastes precious time writing something that cannot be used in the context of UE4.

11

I agree, Unreal shouldn’t be using lower case common words for macro names.

12

Hi, if you’re still trying to get third party code to work in your unreal project, I’d suggest precompiling a unreal friendly wrapper library that an unreal plugin can reference.

So essentially you have your unreal game, which includes an unreal plugin, which references an unreal friendly wrapper library, which contains the third party code… Yeah, it’s garbage.

I suggest if you’re trying to do anything in unreal other than exactly what is built into unreal… don’t use unreal.

13

Why not provide a config macro for backwards compatibility?

  • Redefine all of the macros to something more sensible

  • Fix all of main engine code to use the new macros

  • Supply a config macro, something like

    #if SUPPLY_OLDSTYLE_CHECK

    define check NEW_CHECK

    #endif
    This allows a clear migration path for any code depending on the old macros if it’s really a problem.

Also, I have to agree, it’s pretty bad form to use such common names for macros. Haven’t we learned from min/max?

1 Like
14

Related: UE macros and 3rd party library conflicts - Programming & Scripting - Unreal Engine Forums

For the record, the usual suspects in my experience have been the check, PI, CONSTEXPR and dynamic_cast macros (yes, they redefine dynamic_cast!):

#pragma push_macro("CONSTEXPR")
#undef CONSTEXPR
#pragma push_macro("dynamic_cast")
#undef dynamic_cast
#pragma push_macro("check")
#undef check
#pragma push_macro("PI")
#undef PI
#include <that-3rd-party-library.hpp>
#pragma pop_macro("PI")
#pragma pop_macro("check")
#pragma pop_macro("dynamic_cast")
#pragma pop_macro("CONSTEXPR")
2 Likes
15

For a workaround, see the “Manual fix” part in this question: UE macros and 3rd party library conflicts - Programming & Scripting - Unreal Engine Forums

In short, you can tweak the UBT-generated response files to allow you to include any 3rd party headers before the UE headers get processed and pollute the macro space:

  1. In Intermediate[…]\YourSourceFile.cpp.obj.response file, remove the line /FI"[…]\Engine\SharedPCH.Engine.h"
  2. Include that file in YourSourceFile.cpp after including your 3rd party library (and before any other UE stuff).

The downside is that you need to re-apply this modification every time after UBT chooses to regenerate the response files.

Of course, this is not how things should be. I sincerely hope that Epic chooses to do something about this.

16

Added #undef CONSTEXPR and #undef dynamic_cast to the list… Yes, UE indeed does redefine dynamic_cast via a macro. Unbelievable.

17

I made a small script that generates a pair of headers for undefining and then redefining all macros used by UE.

.com//UnrealMacroNuke

The releases pages of that repo has pre-generated header pairs for various versions of UE.

18

I stumbled upon this while trying to make something as simple as boost beast work with unreal: here is stack overflow question that I asked. I agree that all macro should work within its own namespace and scope, that would resolve a number of such conflicts. You can check that “check” is annoying especially OpenCV 4.0 and Boost, if these libs can be put together independently in a standard C++ program then so should the unreal macros work seamlessly with others. Its a shame that this has not been already taken care of this. I will take a look at Disable/ Allow settings example, but its a dirty pain killer not a cure.

19

Bumping this topic.

It looks like UE-28766 feature request was somehow deleted.

What UE is doing in terms of macro definitions is simply insane. UE4 basically doesn’t comply with STL.

I managed to solve this issue with some python scripting and macro definition guards (undefining them basically) on my files but it is so sad that we have to do this to include our internal libraries and also other large libraries like Boost.

Will Epic ever fix this issue? I mean it doesn’t even make sense for Epic to keep this as it is, C++ based gameplay coding is one of the major powers UE but if that C++ doesn’t doesn’t comply with STL and doesn’t permit easy integration of third party libraries then it doesn’t make any sense why we are coding the gameplay logic in C++, if Epic is not willing to comply with STL and managed to create a sub-set of C++, why not go with C# then?

Solution seems easy enough as well but considering that Epic hasn’t bothered with fixing this for past 2 years, I don’t have high hopes.

20

This made me smile, if this was reddit, you would get gold. I agree as well. xD