现在已经有模块0（当中实现f0），然后模块1和模块2各自都引入了模块0，那么这里模块1和模块2都各自有f0的副本，当一个主程项目又同时引入模块1和模块2时，假若模块0本身没有设计为inline，那么这里主工程必定导致符号重定义。

之所以不设计为inline一个合理的理由是加快编译速度（不同编译单元只引用其声明头文件，源定义在别处，这也是传统C++开发方式），加快链接期速度（因为inline会触发COMDAT机制链接器要在多个定义副本中抉择其一，如果没有inline则省去这一过程），再来一个开发中的原因就是多写个inline其实真的很烦也不够优雅~

而白易在模块设计机制上，就允许你只专心开发源文件，而头文件解析生成的事情交给MakeBEC插件，从而有纯天然的高效且优雅的C++开发体验。

就算是inline方案也未必真的能完全解决多个模块项目之间的冲突问题，试想如果我模块1就绑死依赖了模块0的1.0版本，模块0的1.0与2.0已经有版本上的“大换血级”的不同实现（虽然f0符号还是那个符号），而模块2依赖的是模块0的2.0版本，那么请问现在主程项目中同时引入模块1和模块2，那么f0还能否真的可以inline？

由于C++是分布式的编译体系（根本原因我也可以一针见血指出C++的符号链接的空间是全局扁平的，如果允许有某种机制让各自模块的链接范围仅限定绑定在其子目录中的话），那么对于这个版本管理问题即便是inline还真的无解；

并且就算是到 C++20 Modules 依然也没有解决这个问题~（你要不信的话，我已经帮你测了）

故，在不同的嵌套项目的版本管理之间很难说不出问题。。。

[白易解决模块嵌套子模块的破局之法]

注意：以下改编仅Pro版支持：当一个模块工程内去引入一个子模块时将弹出改编提示，免费版不会显示该界面 默认也不会进行改编；
若是一个主项目工程该改编提示的窗口并不会弹出，若主程遇到符号问题可先另开模块工程去实现符号改编做成子模块形式（主模块内无需套娃再做一层函数封装，本身子模块改编后就是目标符号了）再导入进主程项目即可使用改编后的模块。

以下是以主模块内嵌套子模块依赖的改编示例：

• 这里我们先举源代码级改编的例子：
  
  
  模块0这里直接以源码进行发布bec
  
  
  这里我们点击【确认改编空间】，那么在模块1这个工程内导入的模块0（所有的符号）将会被改编
  
  
  
  namespace{using namespace _M模块1;}
  
  
  然后我们简单对模块1进行一下依赖模块0的封装：
  
  
  然后模块1可以携带模块0依赖进行编译打包，在bec中的结构是这样的：
  
  
  
  于是我们把该模块再放到一个主程项目中导入编译
  
  
  
  
  就现在而言模块0确实已经被隔离了，那如果主项目要想直接调用模块0的是否可以直接add()？
  
  事实上，白易插件的MakeBEC工具之前说过对于匿名命名空间的头文件生成规则是直接过滤，而且匿名命名空间原本的C++特性就是当中使用的代码只扩散在当前所在的编译单元中可见，算是白易对此特性充分的强强联合！
  
  
  那么你现在 在主程项目中完全是完全看不到add这个模块0中的符号的，而且模块0中的add符号也确实从根上被改名为了_M模块1::add
  
  现在再效仿模块1的做法做一个模块2
  
  
  编译后主程中同时再引入模块2：
  
  
  
  
• 然后是编译到lib的模块，同样
  白易做到了深入进obj中COFF格式的二进制级别符号改编
  、
  
  分别查看一下各自的"模块0.lib"导出符号：
  
  
  
  
  然后现在可以直接在主程中同时引入这两了：
  
  
  注意到BEBuild该虚拟目录中已经完全不存在编译单元的源文件了
  正说明它的实现已经转向了已有的lib二进制实现
  
  
  接着我们查看一下主程项目的：BEMod.h
  
  
  其实这些路径是在导入到插件内后才进行的修正，我们回头在源模块1.bec包中直接打开它的BEMod.h看一下
  
  
  那现在主程项目引入的真实模块1文件夹里的BEMod.h呢？
  
  注：VC工程中#pragma comment(lib, ...) 只管到的路径永远是相对于当前工程内的，而不是本头文件，这点跟C/C++头文件的#include预处理包含还不太一样。
  
  是的，如果这里的不进行路径修正的话，必然会导致lib找不到的情况！当然这里确实是有多处进行声明链接了由于指向的都是同个lib，故本身操作是绝对安全的！

那上边你这一说了都是基于C++的，那C语言怎么办？

纯C的话本身也是能改编符号，但没有命名空间这样非常方便的机制，对于非C++源码以及非MSVC编译的C++lib库白易的策略是——只要当前工程是属于模块开发环境（非主程环境）那么在导入子模块时一律直接禁止！（后期会再考虑加入纯C库的符号改编策略，目前对于纯C库的封装我是建议你做成系统模块库——纯C库本身比较适合这个场景）

现在源代码级的模块弹窗告知；

对于lib级的模块弹窗告知：

PS：白易在0.5之后已经计划pro版(预计26年底随1.0 Pro版发布)实现C库的lib级符号改编，尽请期待~

当然作者自己已经有实现过的内部案例：白易模块注释级指令.mht#beExcludeNamespaceSymbol

对于release版本下且开启了全程序优化选项进行的模块编译，它的obj文件并非是标准的COFF格式，它里边的代码实现也并非是目标平台上面向CPU的二进制机器码，而是MSVC当前编译器下的中间字节码！

LTCG搞出的obj格式网上没有任何公开的资料，
也对，易语言支持库开发那会想起来为什么要关掉这个全程序优化了。。

关于这点微软本身也做了解释：

且与.NET那种IL中间语言又还不是一回事，属于每个编译器自带语言

而且这玩意微软也明确说它还存在不同VC之间（即便是2015以上，即便还是同个大版本下的子版本）

看来得禁止用户套这种release版的静态库模块了，除非有源代码或者关闭全程序优化的release静态库否则现有公开的工具没法改名，并且跨只要是不同的VC编译器版本也都还会存在ABI兼容问题，事情可谓非常严重！

故白易在进行BE模块工程初始模板里，就已经写死把release发布版下的配置中把全程序优化（LTCG）的选项给否掉了

参考：
底层原理之链接期的延迟代码生成：https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/may/under-the-hood-link-time-code-generation
Visual Studio 版本之间的 C++ 二进制兼容性：https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170