你可曾想过在一个项目中，使用不同的编译选项，不同的语言标准（C++11/C++14/C++17/C++latest）编译不同cpp？然后统一链接到一个目标文件(dll或者exe)。
混合编译在不同人的脑子里肯定有着完全不同的概念。
最初，能将C++/CLI里将各种代码混在一起编译就叫混合编译。用统一的编译选项，用/clr和/EHa选项编译出的混合代码，用reflector.exe 反编译后能看到所有的代码实现。所有的代码其实都是IL代码，需要借助JIT运行。
第二层级，你可以将native code和托管代码用#pragma unmanaged/#pragma managed进行编译，native code的部分就成了不能用reflector.exe 反编译的，不是IL代码，而是二进制代码，执行效率会得到提高。但用了#pragma unmanaged/#pragma managed编译的cpp，也是在/clr和/EHa的统一编译选项下的编译。某些时候在这种编译选项下会出错，比如Qt的信号槽点新语法会不起作用，需要切换到connect(obj,SIGNAL(signalfunc),otherobj,SLOT(slotfunc));这种旧式连接方式。
另外一个是/clr编译时不能包含<future>头文件，出错信息：
#error directive: <future> is not supported when compiling with /clr or /clr:pure.
这可能是因为<future>包含在“ qthread.h”中，这是qt线程功能所需的。不管怎么设置#pragma unmanaged/#pragma managed都不能消除这个error。
还有，因为应用了/clr选项，就限制了C++的标准只能最高到C++17，最新的C++标准在C++/CLI里是不受支持的。需要-std:c++latest才能启用结构化绑定等new feature是无缘C++/CLI的。
这说明统一的/clr编译选项在某些时候是有限制和副作用的。
最理想的编译是分开编译，统一链接，只对托管代码启用/clr和/EHa选项，对native code仅启用/EHsc选项，这里的关于异常的设置不同是因为在boost里启用动态连接的时候，boost的序列化库不支持/EHa选项。同时在两种代码编译的时候可以分别设置不同的C++语言标准。
在visual studio 2022之前，我一度认为只有mdl里用mki才能控制这种混合编译的方式。
在mdl的sdk里有两个mki文件能有选择地编译托管代码：
- compileForCLRStart.mki
- compileForCLRStop.mki
用法如下：
%include compileForCLRStart.mki
#----------------------------------------------------------------------
# Compile ForwardDeclarationProblem file with debug off so we don't
# get the dummy defs for our native types in the debugger
#----------------------------------------------------------------------
CCompDebugOptions = $(CCompDebugOffSwitch)
CCompDebugOptions =% $[CCompDebugDefault]
CCompOpts + -AI$(MS)Assemblies -AI$(MS)Assemblies/ECFramework -AI$(MS) -AI$(o)
$(o)ElementPropertiesExample$(oext) : $(baseDir)ElementPropertiesExample.cpp
$(o)NativeExample$(oext) : $(baseDir)NativeExample.cpp
$(o)ManagedExample$(oext) : $(baseDir)ManagedExample.cpp
%include compileForCLRStop.mki
可以将native code放在两个mki之外，编译选项将有所不同。
缺陷是还是太过复杂，起码我不通过拷贝，不能完全手写出来这个mke。我一直用的qmake的mke文件，从来没拷贝过，从来都是完全从头手写，因为太简单了。
在visual studio 2022里通过IDE的设置，也可以设置不同的cpp使用不同的编译选项。使用的是msbuild，需要编译project文件，这个我不熟，IDE太过复杂，放弃了。
后面对qmake进行了配置，自定义了编译器，完美解决，如有兴趣，请参阅QMAKE_EXTRA_COMPILERS的相关内容。这里有个链接：[https://wiki.qt.io/Undocumented_QMake]可供参考。
在pro文件里将不同的代码方法放到不同的变量里，就能自动启动clr的分别编译。
SOURCES += nativecode1.cpp nativecode2.cpp
SOURCES_CLR += clrcode1.cpp clrcode2.cpp
几乎没有增加pro编写的难度。根据SOURCES_CLR是否有内容来确定是否启动clr编译和编译哪些cpp文件为IL代码。请细品截图：
mixedCompile.png
需要注意的是，有关链接器的设置应该一致，比如运行时的设置[ MT / MTd / MD / MDd ]，否则造成链接错误。这很好理解，如果有些设置为MT，有些设置为MD，或者同时使用了MTd和MDd，都会导致多个同样的符号链接进来，会产生混淆的错误。
网友评论