【UE4源代码观察】在空白工程中测试跨模块调用函数

本文主要是介绍【UE4源代码观察】在空白工程中测试跨模块调用函数，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目的

在之前的博客【UE4源代码观察】手动建立一个使用UBT进行编译的空白工程中，成功让UBT工作起来了。现在我想要测试编译出的多个模块之间是否能互相调用，我记录下测试的过程。最终工程见 工程GIT链接。

实践

第一部分

首先仿照TestA模块建立TestB模块。
在TestB.h文件中声明了一个函数

int TestBFunc(int x, int y);

并在TestB.cpp中写他的实现

#include"TestB.h"
int TestBFunc(int x, int y)
{return x + y;
}

然后在启动模块TestA的入口函数中尝试调用这个函数：

#include"../TestB/TestB.h"
#include<iostream>
int main()
{std::cout << TestBFunc(3, 2) << std::endl;return 0;
}

为了证明能成功调用，我还include了< iostream >然后用std::cout输出了结果。
启动“生成”，但是失败了:

1>TestA.cpp.obj : error LNK2019: 无法解析的外部符号 "int __cdecl TestBFunc(int,int)" (?TestBFunc@@YAHHH@Z)，该符号在函数 main 中被引用

看来并没有找到这个函数的实现。于是我在TestA.Build.cs中增加了TestB的依赖：

 PrivateDependencyModuleNames.Add("TestB");

错误变成了：

1>LINK : error LNK2001: 无法解析的外部符号 IMPLEMENT_MODULE_TestB
1>D:\0_WorkSpace\UEYaksueTest\Engine\Binaries\Win64\Test1.exe : fatal error LNK1120: 1 个无法解析的外部命令

未找到的 IMPLEMENT_MODULE_TestB应该是由IMPLEMENT_MODULE这个宏定义的，见ModuleManager.h:

#define IMPLEMENT_MODULE( ModuleImplClass, ModuleName ) \\/**/ \/* InitializeModule function, called by module manager after this module's DLL has been loaded */ \/**/ \/* @return	Returns an instance of this module */ \/**/ \extern "C" DLLEXPORT IModuleInterface* InitializeModule() \{ \return new ModuleImplClass(); \} \/* Forced reference to this function is added by the linker to check that each module uses IMPLEMENT_MODULE */ \extern "C" void IMPLEMENT_MODULE_##ModuleName() { } \PER_MODULE_BOILERPLATE \PER_MODULE_BOILERPLATE_ANYLINK(ModuleImplClass, ModuleName)

不过，模块也不一定必须要用IMPLEMENT_MODULE宏，模块中有个属性 bRequiresImplementModule，在官方文档的说明是：
bRequiresImplementModule (Nullable)
此模块的实现是否需要IMPLEMENT_MODULE宏。大多数UE4模块都有此需要，因为我们使用IMPLEMENT_MODULE宏来执行其他全局重载（例如运算符新建/删除向GMalloc的传递）。

如果在TestB.build.cs中加：

 bRequiresImplementModule = false;

就可以编译成功，程序也运行正常。

第二部分

我又建立了一个TestC模块，想要尝试使用IMPLEMENT_MODULE( ModuleImplClass, ModuleName )这个宏。

这个宏的括号内两个符号，第二个是这个模块的名字，填“TestC”就好，而第一个是模块的实现类，需要继承自 IModuleInterface，为此我需要IModuleInterface的定义。
IModuleInterface的定义在ModuleInterface.h中，我将他拷贝到了自己的工程中，虽然他include了"CoreTypes.h"文件，但是我看似乎是没有必要的，因此暂时先注掉了。另外，他的成员函数都是空的并且实现都在头文件中，因此不需要cpp文件与之匹配。
下面，在TestC.h中继承了一个模块接口：

#include"../../Runtime/Core/Public/Modules/ModuleInterface.h"
class TestCModule: public IModuleInterface
{ 
public:static int TestCModuleFunction(int x, int y);
};

之后我想把 IMPLEMENT_MODULE 这个宏的定义也拷贝过来，可惜他本身牵扯到很多内容，最主要是这个宏也包括了PER_MODULE_BOILERPLATE这个宏，他的内容在ModuleBoilerplate.h可以看到，它实际想要为模块重载内存分配符号（new 和 delete）:

/*** Override new + delete operators (and array versions) in every module.* This prevents the possibility of mismatched new/delete calls such as a new[] that* uses Unreal's allocator and a delete[] that uses the system allocator.*/
#if USING_CODE_ANALYSIS#define OPERATOR_NEW_MSVC_PRAGMA MSVC_PRAGMA( warning( suppress : 28251 ) )	//	warning C28251: Inconsistent annotation for 'new': this instance has no annotations
#else#define OPERATOR_NEW_MSVC_PRAGMA
#endif#if !FORCE_ANSI_ALLOCATOR
#define REPLACEMENT_OPERATOR_NEW_AND_DELETE \OPERATOR_NEW_MSVC_PRAGMA void* operator new  ( size_t Size                        ) OPERATOR_NEW_THROW_SPEC      { return FMemory::Malloc( Size ); } \OPERATOR_NEW_MSVC_PRAGMA void* operator new[]( size_t Size                        ) OPERATOR_NEW_THROW_SPEC      { return FMemory::Malloc( Size ); } \OPERATOR_NEW_MSVC_PRAGMA void* operator new  ( size_t Size, const std::nothrow_t& ) OPERATOR_NEW_NOTHROW_SPEC    { return FMemory::Malloc( Size ); } \OPERATOR_NEW_MSVC_PRAGMA void* operator new[]( size_t Size, const std::nothrow_t& ) OPERATOR_NEW_NOTHROW_SPEC    { return FMemory::Malloc( Size ); } \void operator delete  ( void* Ptr )                                                 OPERATOR_DELETE_THROW_SPEC   { FMemory::Free( Ptr ); } \void operator delete[]( void* Ptr )                                                 OPERATOR_DELETE_THROW_SPEC   { FMemory::Free( Ptr ); } \void operator delete  ( void* Ptr, const std::nothrow_t& )                          OPERATOR_DELETE_NOTHROW_SPEC { FMemory::Free( Ptr ); } \void operator delete[]( void* Ptr, const std::nothrow_t& )                          OPERATOR_DELETE_NOTHROW_SPEC { FMemory::Free( Ptr ); } \void operator delete  ( void* Ptr, size_t Size )                                    OPERATOR_DELETE_THROW_SPEC   { FMemory::Free( Ptr ); } \void operator delete[]( void* Ptr, size_t Size )                                    OPERATOR_DELETE_THROW_SPEC   { FMemory::Free( Ptr ); } \void operator delete  ( void* Ptr, size_t Size, const std::nothrow_t& )             OPERATOR_DELETE_NOTHROW_SPEC { FMemory::Free( Ptr ); } \void operator delete[]( void* Ptr, size_t Size, const std::nothrow_t& )             OPERATOR_DELETE_NOTHROW_SPEC { FMemory::Free( Ptr ); }
#else#define REPLACEMENT_OPERATOR_NEW_AND_DELETE
#endifclass FChunkedFixedUObjectArray;#ifdef DISABLE_UE4_VISUALIZER_HELPERS#define UE4_VISUALIZERS_HELPERS
#elif PLATFORM_UNIX// GDB/LLDB pretty printers don't use these - no need to export additional symbols. This also solves ODR violation reported by ASan on Linux#define UE4_VISUALIZERS_HELPERS
#else#define UE4_VISUALIZERS_HELPERS \uint8** GNameBlocksDebug = FNameDebugVisualizer::GetBlocks(); \FChunkedFixedUObjectArray*& GObjectArrayForDebugVisualizers = GCoreObjectArrayForDebugVisualizers;
#endif// in DLL builds, these are done per-module, otherwise we just need one in the application
// visual studio cannot find cross dll data for visualizers, so these provide access
#define PER_MODULE_BOILERPLATE \UE4_VISUALIZERS_HELPERS \REPLACEMENT_OPERATOR_NEW_AND_DELETE

对于目前的空白工程而言，内存管理相关的内容是没有的，因此我就算将一个空的IMPLEMENT_MODULE宏拷贝过来也意义不大，目前我只是想尝试不让bRequiresImplementModule为false的情况下编译通过，这其实只用在TestC.cpp最后补上一句就可以了：

extern "C" void IMPLEMENT_MODULE_TestC() { }

这一段本来会由IMPLEMENT_MODULE包括，但这里手动写上去了。
之后编译成功，程序也运行正常。

这篇关于【UE4源代码观察】在空白工程中测试跨模块调用函数的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---