来源:
Ari Arnbjörnsson大佬的推文twitter.com文档源:
Ari Arnbjörnsson大佬的PPTdocs.google.com今天(X)很久很久之前(√)无意间刷到了Ari Arnbjörnsson大佬,关于UE4模块的解析,完美的解答了我心中多年的疑问.还有一些相关的问题,一起记录在这里.(建议先看上面的PPT )
如有理解不当的地方,恳请指正
为什么模块代码文件要区分Public和Private目录?
答:是为了满足模块导出(从模块导出类或者函数供其它模块使用)机制.因为模块里的代码默认是不暴露给其它模块的,所以UE4约定:把需要导出(全导出或部分导出)给其它模块使用的代码文件的头文件放在模块的Public目录下.
- 模块默认不暴露任何类或函数(如何暴露请看PPT)
- 不想暴露的头文件可以放进Private文件夹
- 不会被其它模块引用的模块,可以不区分Public/Private文件夹.(比如游戏(主)模块)
Public目录下只放头文件,因为.cpp文件放这里,其它模块也无法' #include "xxx.cpp" '.IncludePathModuleNames,DependencyModuleNames的区别?
答:
*注意,问题里没有Public/Private前缀
二者都能使本模块可以包含其它模块Public目录下的头文件,从而调用函数.
但IncludePathModuleNames只能调用定义全部在头文件里的函数.
// Class.h
因为在编译时会将包含的头文件的内容都 拷贝一份到.cpp里,所以定义全部在头文件里的函数能正常工作.
而这带来的问题是:同一个函数,被编译多次(根据它被包含的次数),在大型项目里将 拖慢编译速度.
所以我们为了让函数只编译一次,才会把函数定义放在cpp文件里.
使用DependencyModuleNames时,会进行对两个模块进行链接.故不存在此问题.
只有与其它模块链接之后,才能使用其它模块的定义在.cpp里函数( 若使用了定义在.cpp内函数,但又没将引用到的模块添加到DependencyModuleNames,就会获得"无法解析的外部符号(unresolved external symbol)"错误)
*IncludePathModuleNames是过时的用法,现在一般只用DependencyModuleNamesPublicIncludePathModuleNames, PublicDependencyModuleNames的区别?
PrivateIncludePathModuleNames, PrivateDependencyModuleNames的区别?
PublicDependencyModuleNames, PrivateDependencyModuleNames的区别?
答答答:要回答这个问题,除了要理解"Include与Dependency",就剩明白Public和Private的含义.
其实我也是到现在才完全明白,它俩其实和C++里的访问控制符是类似的,只是多了点小细节
C
*由于IncludePathModuleNames已过时,下面只讨论DependencyModuleNames.
结论:Private隐藏所有信息,Public只传递头文件信息.链接永不传递,需显式在Build.cs里添加.
对于三个模块,无法获得Private中模块的任何信息,可以获得Public中模块的头文件信息.
对于两个模块Public/Private无意义.(可以随意用)最终结论:建议只使用PrivateDependencyModuleNames.杜绝迷惑.(但应该考虑过多模块静态链接的问题？)
图片源文件下载
MinimalAPI说明符的作用?
答:暴露该类的类型信息让其它模块可以
- Cast到该类型
- 继承该类型
- 使用内联函数
[YourModuleName]_API宏的作用?
答:
- 放函数声明前用于暴露该函数
- 放类声明前用于暴露该类的所有内容
如何正确的包括头文件(使用来自其它模块的类)?
答:首先找到该头文件的完整路径
- 在.h或cpp中包括头文件#include "Path" : Path是完整路径中Classes或Public的斜杠之后的部分
- Classes目录是过时的东西,现在都放在Public目录下
- 在build.cs中添加模块关系 : 模块名是完整路径中Classes或Public之前的部分
模块的类型有多少种可以选择?
答:请查看Projects模块中的EHostType::Type.(UBT里也能找到一样的定义)
- Engine/Source/Runtime/Projects/Public/ModuleDescriptor.h
- Engine/Source/Programs/UnrealBuildTool/System/ModuleDescriptor.cs
模块的加载时期的有多少种可以选择?
答:请查看Projects模块中的ELoadingPhase::Type.(UBT里也能找到一样的定义)
- Engine/Source/Runtime/Projects/Public/ModuleDescriptor.h
- Engine/Source/Programs/UnrealBuildTool/System/ModuleDescriptor.cs
Precompiled Headers(PCH)文件有什么用?
答:由于编译代码时一般不会单独编译头文件,头文件被包含到每个.cpp里,随着.cpp文件一起编译.因此当多个.cpp包含同一份.h时,就带来了重复编译的问题.
于是PCH出现了,这个文件里的头文件只会被编译一次.
- PCH包含了所有最常使用的头文件
- 优先编译
- 仅在这些最常使用的头文件发生变化时,重新编译一次
- 包含了PCH的.cpp也会重新编译
- 最好用在引擎代码或者那种很少变动的代码
Private PCH 和 Shared PCH又是什么?有啥用?
答:它俩是特殊一点的PCH,只需记住几（×）1（√）点，
Private PCH是给本模块用的PCH，Shared PCH是给 依赖本模块的模块用的PCH
一个模块可以使用其他模块定义的Shared PCH
一个模块不能使用自己定义的Shared PCH
模块对PCH的选择只有三个：
-使用本模块定义的Private PCH
-使用引擎自动从 本模块依赖的模块定义的Shared PCH中,选出一个最佳PCH
- 不使用PCH
两者需要在模块的build.cs文件中手动指定
PrivatePCHHeaderFile - 不要手动在模块的.h/.cpp中包含该文件
- UBT会自动把它注入到每个被编译的.cpp中
- PCH应该是一种优化层面的东西
- 不要把它当作一种快捷的"include all"的方式,还是要坚持"IWYU,只包含用到的东西"
- 你的代码在没有PCH的时候,也能编译通过
对于Shared PCH
- UE4将自动选择最优的Shared PCH，最终的目的是让选择的Shared PCH尽可能多的涵盖本模块用到的头文件。
Shared PCH的选择范围是本模块依赖的模块中定义的Shared PCH
假如模块A依赖Slate，Core以及CoreUOject模块，且没定义Private PCH，
且只有Slate及Core模块中定义了Shared PCH，
那么，A的Shared PCH就只能从Slate, Core两个模块中选
选哪一个呢？
基于得分来选择——以它俩依赖的<定义了Shared PCH的> 模块数量来作为它们的分数
假设Core模块依赖了TraceLog, Json,假如只有TraceLog模块中定义了Shared PCH,
那么它得1分
假设Slate模块依赖了Core, SourceControl, Json模块，假如Json模块中定义了Shared PCH，
那么它得2分(Core 1 + Json 1)
而且很容易看出，由于Slate的依赖项里包含了Core,那么它Shared PCH很可能包含了大部分Core模块里的头文件，以及其它 额外的头文件，这样，我们就会理所当然的选择使用Slate的Shared PCH，因为我们的模块使用到的头文件，也在Slate的Shared PCH里的概率更大。
因此我们将会选择Slate模块的Shared PCH作为本模块的PCH。
- 它是一个用于给依赖于本模块的模块使用的PCH
- 在UE4的一些重要且常用的模块里可以看到它
- 具体来说:UnrealEd, Engine, Slate, CoreUObject, Core 等.
- 在UE4的一些重要且常用的模块里可以看到它
- 多个模块使用同一个Shared PCH时,它也只会编译一次
IWYU是什么?有什么作用?
答:IWYU就是Include-What-You-Use,类似于一种代码规范,正确的说法或许是依赖模型(dependency model, 描述文件之间的依赖关系).
在工程中应用IWYU将会带来减少编译时间与重编次数以及利于重构等多种好处.
了解更多有关IWYU:
include-what-you-use的好处github.com UE4官方文档-IWYUdocs.unrealengine.com
543
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
