C 和 C++界面

发布于 2024-12-10 05:55:22 字数 46 浏览 0 评论 0原文

为什么向 C++ 代码提供其他语言的包装器比向 C 代码提供包装器要困难得多?

why it is much more difficult to provide wrappers in other languages to C++ code as opposed to C code ?

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

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

发布评论

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

评论(3

婴鹅 2024-12-17 05:55:22

每种语言在与其他语言交互时都有其独特的挑战。

您可以认为 C++ 在某种意义上“更困难”,因为它具有其他语言所没有的功能。以多重继承为例。这是一个非常棘手的功能,很多人干脆说根本不要使用。但如果使用它,你会如何将其翻译成另一种语言?

但关键是,语言本身不再难以包装 - 问题在于映射其他语言中不存在的功能几乎是不可能的。但是,如果该功能在该语言中不存在,您必须问自己为什么它不存在,以及您是否应该首先使用它。

Every language has it's unique challenges when it comes to interacting with other languages.

You could consider C++ 'more difficult' in a sense due to its features that other languages don't have. Take for example multiple inheritance. This is a very tricky feature, and is one that many people simply say not to use at all. But if it is used, how would you translate that into another language?

The key point, though, is that the language itself is no more difficult to wrap - the problem is in mapping features that don't exist in other languages is darn near impossible. However, if the feature doesn't exist in that language, you have to ask yourself why it's not in there and if you should even be using it at all in the first place.

滥情稳全场 2024-12-17 05:55:22

这因库本身及其设计方式而有很大差异。

一般来说,C++ 更复杂,因为它有对象、类和接口,而 C 主要是函数。类的成员函数的命名和调用方式不同,因此包装它们需要更多的工作才能提供等效的名称。

一旦库被包装以提供等效的接口并处理调用约定,下一个区别是 C++ 允许对象作为函数参数传递,这可能需要深度复制和类似的操作。在采用纯粹指针的库中,例如 COM,这不是问题(这也是 COM 与如此多语言和其他系统可互操作的部分原因),但即使在 C++ 中,处理必要的复制代码也非常依赖于编译器。

This varies significantly by the library itself and how its designed.

Speaking very generally, C++ is more complex in that it has objects, classes and interfaces, where C is primarily functions. Member functions of a class are named and called differently, so wrapping them takes a bit more work to provide equivalent names.

Once the library is wrapped to provide an equivalent interface and calling conventions are handled, the next difference is C++ allowing objects to be passed as function parameters, which may necessitate deep copies and similar. In a library taking purely pointers, for example COM, this isn't a problem (which is part of why COM is interoperable with so many languages and other systems), but handling the necessary copy code is very compiler-dependent even within C++.

机场等船 2024-12-17 05:55:22

在某种程度上扩展其他人给出的答案,另一个需要考虑的令人讨厌的问题是例外。在操作系统、语言或运行时库中可以通过多种方式实现异常。 C++ 实现它们的方式在某些重要方面是独一无二的。如果从另一种语言调用 C++ 例程并引发异常,则不完全清楚应如何处理。一种方法是简单地声明所有此类异常都是致命的。这并非不合理,但它阻止了其他语言被用来执行原本有用的任务。例如,考虑一个例程,该例程将枚举项目列表并计算总和;如果对其中一项的求值引发异常,则该异常应向上渗透到例程的调用方以枚举列表。但是,如果枚举列表的例程是用另一种语言编写的,则安排异常通过各层正确渗透可能会出现问题。

Extending somewhat upon answers given by others, another nasty issue to consider is exceptions. There are a number of ways exceptions can be implemented in an operating system, language, or run-time library. The way C++ implements them is in some significant ways unique. If a C++ routine is called from another language and throws an exception, it's not entirely clear how that should be handled. One approach would be to simply declare all such exceptions fatal. Not unreasonable, but it prevents other languages from being used to perform what would otherwise be useful tasks. For example, consider a routine that would enumerate through a list of items and compute the sum; if the evaluation of one of the items throws an exception, the exception should percolate up to the caller of the routine to enumerate the list. If the routine to enumerate the list were written in another language, though, arranging for the exception to percolate up properly through the layers could be problematic.

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