包装我们的软件库以服务于 C++ 的最佳方式是什么?和 C# 客户端应用程序?

发布于 2024-09-29 09:09:47 字数 507 浏览 0 评论 0原文

我正在开始一个新项目,其核心产品是软件库。我们将包装现有的代码,用 C++ 编写,因为它的数值非常密集;我们拥有并编译这个核心代码。

我相信我们将有两种主要的客户类型: 1.用C++编写的应用程序,可能是MFC 2.用C#.NET编写的应用程序。

问题:为了向这两种客户端类型提供“理想”界面,我们使用什么技术?例如,我们可以提供两个接口,一个为 C++ 客户端使用 C/C++ 函数和回调,另一个为 C# 客户端使用 C#.NET?另外,原则上,这可以在一个 DLL 中很好地完成吗?还是我们需要两个(或更多)?

其他信息...客户端应用程序是嵌入式的,而不是台式机或笔记本电脑;假设任何 UI 都不是基于 Windows 的。此外,我们还必须针对 32 位和 64 位进行编译和测试,可能是 32 位上的 C++ 和 64 位上的 C#。

我在这里道歉 - 我意识到这个问题可能已经被问过并回答过,但如果是这样,我无法找到它。

I am starting work on a new project where the core product is a Software Library. There is existing code we will be wrapping, written in C++ because it is very numerically intensive; we own and compile this core code.

I believe we will have two prominent client types:
1. App written in C++, probably MFC
2. App written in C#.NET.

The Question: In order to offer an "ideal" interface to both these client types, what technology do we use? For example, we could offer two interfaces, one using C/C++ functions and callbacks for the C++ clients, and the other using C#.NET for the C# clients? Also, in principle, could this be done nicely in one DLL, or will we want two (or more)?

Other info... Client apps are embedded, not a desktop or laptop; assume any UI is not Windows-based. Also we will have to compile and test for both 32-bit and 64-bit, probably C++ on 32-bit and C# on 64-bit.

My apologies here -- I realize this question may have been asked and answered previously, but if so, I was not able to find it.

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

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

发布评论

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

评论(1

半衬遮猫 2024-10-06 09:09:48

有趣的问题,我期待其他答案。

一种可能的解决方案(如果可能不是最好的):如果您的库代码遵循面向对象的实践,您可以用 C++ 编写核心功能,然后围绕核心类提供单独的 COM 包装器类(也在 C++ 中)。这将允许您通过 COM 互操作使用 .NET 中的库组件。我不知道这有多高效——我怀疑性能通常应该很好——而且 COM 有一些明显的缺点(例如没有泛型),因此这可能不是最佳解决方案。

如果您的库不是面向对象的,您仍然可以使用 P/Invoke 调用从 .NET 中的任何 DLL 导出的单个函数...如果您沿着这条路线走下去,很可能您最终会得到一个 C# 包装器。 C++ DLL。

Interesting question, I'm looking forward to other answers.

One possible solution, if probably not the best: If your library code follows object-oriented practices, you could write the core functionality in C++ and then provide separate COM wrapper classes around the core classes (also in C++). This would allow you to use your library components from .NET via COM interop. I don't know how efficient that would be — I suspect performance should generally be fine —, and COM has some obvious drawbacks (no generics, for example), so that may not be the optimal solution.

If your library is not object-oriented, you can still call single functions exported from any DLL in .NET using P/Invoke... if you go down this route, it's likely that you'll end up with a C# wrapper around your C++ DLL.

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