C++\CLIbentley开发C++ 2a

纯C++和托管代码的混合编译

2022-06-13  本文已影响0人  左图右码

你可曾想过在一个项目中,使用不同的编译选项,不同的语言标准(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文件能有选择地编译托管代码:

  1. compileForCLRStart.mki
  2. 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,都会导致多个同样的符号链接进来,会产生混淆的错误。

上一篇下一篇

猜你喜欢

热点阅读