使用非托管接口包装托管

发布于 2024-12-03 18:40:10 字数 348 浏览 6 评论 0原文

我有一个公开一些接口的非托管库。用户可以实现接口并通过自定义实现将它们粘贴到库中。

我想为这个库提供一个托管包装器。 用托管接口包装非托管接口很容易。但就我而言,我想支持各种接口的用户实现,这意味着我需要采用接口的托管实现,并使用其非托管对应部分将其包装,然后再将其发送到库的非托管部分的深处。

我尝试过类似的操作:

class UnmanagedWrapper {
DoSomething() {m_clr.DoSomething();}
IManaged^ m_clr;
}

但编译器正确地声明,我不能在非托管类中拥有托管成员。

我可以在这里做一些优雅的事情吗?

I have an unmanaged library exposing some interfaces. Users can implement interfaces and stick them into the library with their custom implementation.

I would like to supply a managed wrapper for this library.
Wrapping an unmanaged interface with a managed one is easy. But in my case I would like to support user implementations of various interfaces which means I need to take a managed implementation of an interface and wrap it using its unmanaged counterpart before I send it into the depths of the unmanaged part of the library.

I tried something like:

class UnmanagedWrapper {
DoSomething() {m_clr.DoSomething();}
IManaged^ m_clr;
}

But I cannot have managed members within an unmanaged class, the compiler rightfully claimed.

Can I do anything elgant here?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

讽刺将军 2024-12-10 18:40:10

以下是当一个库不受托管并且托管语言使用这些库时解决方法的一些相关信息。

此信息的上下文是在 Visual Studio 中使用 GoogleTest 的一种方法:

获取从 Google C++ 测试框架开始

对于 Visual C++ 用户的重要说明如果您将测试放入
库和您的 main() 函数位于不同的库或您的
.exe 文件,这些测试将不会运行。原因是视觉上的一个错误
C++。当您定义测试时,Google Test 会创建某些静态
对象来注册它们。这些对象没有被引用
其他地方,但它们的构造函数仍然应该运行。什么时候
Visual C++ 链接器发现库中没有任何内容被引用
其他地方它把图书馆扔了出去。你必须参考你的
包含主程序测试的库,以防止链接器
丢弃它。以下是具体操作方法。在你的库代码中的某个地方
声明一个函数:

__declspec (dllexport) int PullInMyLibrary() { return 0; } }

如果您将测试放在静态库(而不是 DLL)中,则 __declspec(dllexport) 是

不需要。现在,在您的主程序中,编写调用的代码
该函数:

 int PullInMyLibrary(); 
   静态 int 虚拟 = PullInMyLibrary();

这将
保留您的测试引用,并使它们自行注册
启动。

此外,如果您在静态库中定义测试,请添加
/OPT:NOREF 到您的主程序链接器选项。如果您使用 MSVC++ IDE,
转到您的 .exe 项目属性/配置
属性/链接器/优化并将引用设置设置为保留
未引用的数据 (/OPT:NOREF)。这将阻止 Visual C++ 链接器
丢弃最终测试中生成的单个符号
可执行文件。

不过,还有一个陷阱。如果您使用 Google Test 作为静态
库(这就是 gtest.vcproj 中定义的方式)您的测试必须
也驻留在静态库中。如果你必须将它们放在 DLL 中,
您还必须更改 Google Test 以构建到 DLL 中。否则
您的测试将无法正确运行或根本无法运行。将军
这里的结论是:让你的生活更轻松 - 不要在中编写测试
图书馆!

Here is some related information for work arounds when one library is unmanaged and a managed language uses those libraries.

The context of this information is a way to use GoogleTest in Visual Studio:

Getting started with Google C++ Testing Framework

Important note for Visual C++ users If you put your tests into a
library and your main() function is in a different library or in your
.exe file, those tests will not run. The reason is a bug in Visual
C++. When you define your tests, Google Test creates certain static
objects to register them. These objects are not referenced from
elsewhere but their constructors are still supposed to run. When
Visual C++ linker sees that nothing in the library is referenced from
other places it throws the library out. You have to reference your
library with tests from your main program to keep the linker from
discarding it. Here is how to do it. Somewhere in your library code
declare a function:

__declspec (dllexport) int PullInMyLibrary() { return 0; }

If you put your tests in a static library (not DLL) then __declspec(dllexport) is

not required. Now, in your main program, write a code that invokes
that function:

   int PullInMyLibrary(); 
   static int dummy = PullInMyLibrary();

This will
keep your tests referenced and will make them register themselves at
startup.

In addition, if you define your tests in a static library, add
/OPT:NOREF to your main program linker options. If you use MSVC++ IDE,
go to your .exe project properties/Configuration
Properties/Linker/Optimization and set References setting to Keep
Unreferenced Data (/OPT:NOREF). This will keep Visual C++ linker from
discarding individual symbols generated by your tests from the final
executable.

There is one more pitfall, though. If you use Google Test as a static
library (that's how it is defined in gtest.vcproj) your tests must
also reside in a static library. If you have to have them in a DLL,
you must change Google Test to build into a DLL as well. Otherwise
your tests will not run correctly or will not run at all. The general
conclusion here is: make your life easier - do not write your tests in
libraries!

梅窗月明清似水 2024-12-10 18:40:10

也许 gcroot 就是您想要的想:

class UnmanagedWrapper {
    DoSomething() {m_clr.DoSomething();}
    gcroot<IManaged^> m_clr;
}

Maybe gcroot<> is what you want:

class UnmanagedWrapper {
    DoSomething() {m_clr.DoSomething();}
    gcroot<IManaged^> m_clr;
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文