C++14, Sol2 and Unreal 4, how?

Development Programming & Scripting
1

I’m desperately trying to make the excellent Lua wrapper Sol2 work with UE4 C++ in Visual Studio 2015 for a Windows game.
The problem is that Sol2 requires C++14(/17) and it seems that UE4 only uses C++11 (even though VS2015 has a C++14 compiler by default), which results in ton’s of error messages (i’ve listed some here) when the compiler is trying to go through the sol2 file (i’m using the single-header file version).
Sol2 works with every other software project i’ve done so far, it’s only UE4 that has these problems with it.

Is it possible to make/compile UE4 so it uses C++14(/17) in VS2015? If so, how (if possible, with details)?

I’ve tried looking into the “\Engine\Source\Programs\UnrealBuildTool\Windows\VCToolChain.cs” file but i couldn’t find any compiler options for VS2015 that i could make any use of, i think the only compiler options i could find in that file was for the Clang compiler:

if (WindowsPlatform.bCompileWithClang)
			{
				if (!WindowsPlatform.bUseVCCompilerArgs)
				{
					Arguments.Append(" -std=c++11");
					Arguments.Append(" -fdiagnostics-format=msvc");
					Arguments.Append(" -Xclang -relaxed-aliasing -Xclang --dependent-lib=msvcrt -Xclang --dependent-lib=oldnames -gline-tables-only -ffunction-sections");
				}

but i’m using Visual Studio 2015, not Clang.

I know there was a topic about this last december

but the method that person used doesn’t work for me (not sure if that other person used a compiler other than the one from VS2015 and if the file structure has changed since then, none of the subfolders of my UnrealBuildTool folder does have any ToolChain.cs file nor any config file for Windows with a “GetCompileArguments” function).

Any help is greatly appreciated. :slight_smile:

EDIT : SOLUTION
It seems that the new Sol2 release is UE4 compatible.

There is only one thing you need to pay attention to :
When including the “sol.hpp” in an UE4 project you need to wrap it around in an #undef and #define shell for the check() macro, like this:

#undef check
#include "sol.hpp"
#if DO_CHECK
	#define check(expr) { if(UNLIKELY(!(expr))) { FDebug::LogAssertFailedMessage( #expr, __FILE__, __LINE__ ); _DebugBreakAndPromptForRemote(); FDebug::AssertFailed( #expr, __FILE__, __LINE__ ); CA_ASSUME(false); } }
#else
	#define check(expr) { CA_ASSUME(expr); }
#endif

(the first #define check(expr) { if(UNLIKELY… ) should be one consistent line, here it seems to be broken up)

The reason for that is because Unreal4 uses several “#define check(expr)…” macros and sol2 uses check(expr) aswell, but in a different way, so check() needs to be undefined when including sol.hpp and then redefined when the include code returns to UE4.

There could also be compiler warnings like

warning C4628: digraphs not supported with -Ze. Character sequence '<:' not interpreted as alternate token for '['

But those can be ignored.
If you want to get rid of these warnings you can manually search for any occurence of “::std::” and “::sol::” in the sol.hpp and change it to “std::” and “sol::” (aka remove the “::” global scope prefixes so it only says “std::” and “sol::”), its only like 4 lines

So if anyone else needs a great and fast C++ Lua Wrapper for UE4, feel free to use Sol2
Happy scripting :slight_smile:

2

I found some refrences of C++11 configuration in

\Engine\Source\Programs\UnrealBuildTool\System\QMakefileGenerator.cs

You might investigate that

3

Hey StefanHohnwald,

https://docs.unrealengine.com/latest/INT/Programming/Development/CodingStandard/index.html

As stated in the Coding Standard for Unreal:

C++11 and Modern Language Syntax

Unreal Engine is built to be massively portable to many C++ compilers, so we are careful to use features that are compatible with the compilers we can imagine supporting. Sometimes features are so useful that we will wrap them up in macros and use them pervasively, but usually we will wait until all of the compilers we could imagine supporting are up to the latest standard.

We are utilizing certain C++11 language features that appear to be well-supported across modern compilers, such as range-based-for, move semantics and lambdas. In some cases, we are able to wrap up usage of these features in preprocessor conditionals (such as rvalue references in containers.) However, certain language features we may opt to avoid entirely until we are confident we will not be surprised by a new platform appearing that cannot digest the syntax.

Unless specified below as a modern C++ compiler feature we are supporting, you should refrain from using compiler-specific language features unless they are wrapped in preprocessor macros or conditionals and used sparingly.

To me, this is explaining that unless you want to do a lot of preprocessor work, you will have to use Unreal Engines coding standard, which is C++ 11. (I don’t think it will be as easy as changing a single compiler flag and everything will continue to work)

4

Thank you very much for your answer.
It turns out that the main culprit was that both sol2 and UE4 have their own macros for “check”, which i fixed by undefining and redefining UE4s check before/after i included sol2s hpp

#undef check
#include "sol.hpp"
#define check(expr)				{ if(UNLIKELY(!(expr))) { Debug::LogAssertFailedMessage( #expr, __FILE__, __LINE__ ); DebugBreakAndPromptForRemote(); FDebug::AssertFailed( #expr, __FILE__, _LINE__ ); CA_ASSUME(false); } }

This seems to get rid of the errors, however two new errors orrcur:

That gets rid of all the errors, only a few new errors are thrown:

2>\sol2\Includes\sol.hpp(1028):` error C4583: 'sol::storage_t<T>::value_': destructor is not implicitly called

and

2>\sol2\Includes\sol.hpp(1028): error C4583: 'sol::storage_t<T>::value_': destructor is not implicitly called

All these two constructor/destructor errors get thrown by this template in sol.hpp:

template <class T>
union storage_t
{
  unsigned char dummy_;
  T value_;

  constexpr storage_t( trivial_init_t ) noexcept : dummy_() {};

  template <class... Args>
  constexpr storage_t( Args&&... args ) : value_(constexpr_forward<Args>(args)...) {}

  ~storage_t(){}
};

Does UE4 have any special convention for using constructors/destructors in third party code? Because again, with any other game project i’ve worked on sol2 worked, so i guess it must be some UE4 quirk.

5

The problem with using Sol2 was solved, i edited the first post and put the solution below the initial problem statement.

6

In that case post it as answer please and mark as resolved