GObject 与 C++：GObj 提供哪些优势，以及它在速度/大小方面的比较如何？
它为 C++ 等面向对象语言提供了什么？或者没有它就无法使用GTK+？
假设两个示例都使用相同的编译器，就可执行文件的大小和速度而言，对象的 GObject 实现是否与 C++ 具有相似的质量？或者是否存在一些权衡，因为 GObject 提供了额外的功能，因此速度会变慢？
What does it offer to an object oriented language such as C++? or is it not possible to use GTK+ without it?
Is the GObject implementation of objects is of a similar quality to that of C++ in terms of the size and speed of an executable assuming both examples use the same compiler? Or are there some trade-offs where GObject would be slower on the account of additional capabilities it provides?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
GObject（有点像 Windows 世界中的 COM）是一个 C API，其设计时考虑到了跨语言互操作性。
这意味着您可以在任何支持调用 C 函数的语言中使用 GObject，但这使得用非 C 语言编写真正可从任何语言重用的 GObject 变得非常困难（如果您编写例如，Python 中的 GObject 派生类，每次您想在 C 中使用此类中的对象时，都必须嵌入 Python 解释器。
可以半自动化地创建多种语言（例如 Python、Perl、JS 等）的绑定，这就是 GObject 的优势之一。这说明了 GObject 提供的 API 有点不透明，我承认，这是很难彻底理解的。
不幸的是，它也不太适合 C++ 语言。 GObject 与 C++ 类没有微不足道的关系，即使绑定可用 (Gtkmm)，也不可能轻松编写“继承自 GObject”的 C++ 类并将其公开给外界。你必须为此编写C。
[世界需要的是 C++ 语言的某种扩展，这将使与 GObject 的互操作变得容易，有点像 Windows 上的 C++Cx，但是 1) 这是一项艰巨的任务，也许是可以实现的通过 GCC 插件，以及 2) 在 Gnome 世界中，或者一般在 Linux 世界中，没有向 C++ 发展的动力（KDE 是一个值得注意的例外）。现在我们被 Gtkmm 绑定困住了。]
GObject (a bit like COM in the Windows world) is a C API designed with cross language interoperability in mind.
This means that you can use GObjects in any language which supports calling C functions, but this makes it very difficult to write GObjects in a non-C language which are truly reusable from any language (if you write a GObject derived class in say, Python, you'd have to embed a Python interpreter every time you wanted to use objects from this class in C).
It is possible to semi-automate the creation of bindings for many languages (eg. Python, Perl, JS etc), and here lies one of the strengths of GObject. This accounts for the somewhat opaque API that GObject provides, which is, I confess, quite difficult to understand thoroughly.
Unfortunately, it doesn't fit well within the C++ language either. GObjects have no trivial relationship with C++ classes, and even if bindings are available (Gtkmm) it is not possible to easily write a C++ class "inheriting from GObject" and expose it to the world. You have to write C for this.
[What the world would need would be some kind of extensions to the C++ language which would make it easy to interop with GObject, a little like C++Cx on Windows, but 1) it is a difficult task, perhaps achievable through a GCC plugin, and 2) there is no momentum towards C++ in the Gnome world, or generally in the Linux world (KDE being a notable exception). For now we are stuck with the Gtkmm bindings.]
Wikipedia 上有关 GObject 的文章包含与 C++ 的比较。他们提到的一些事情是缺乏多重继承和信号的存在。此外，GObject 还受益于这样一个事实：导出的 C 函数的名称与 C++ 不同，不取决于您选择的编译器。因此，如果您要使用 GObject 开发一个面向对象的库，它可能比 C++ 库更容易链接。
查看以 GObject 为目标的 Vala 编程语言也会很有趣。
The article on GObject from Wikipedia includes a comparison with C++. Some of the things they mention is the lack of multiple inheritance, and the presence of signals. Additionally, GObject benefits from the fact that the names of exported C functions do not, unlike C++, depend on your choice of compiler. So if you were to develop an object-oriented library using GObject, it would probably be easier to link with than a C++ one.
It would also be interesting to look at the Vala programming language, which targets GObject.
对 Vlad 暗示的一些内容进行一点阐述：支持 C 的一个主要观点是，它使编译器或语言之间的互操作性成为“可能”（保证），因为它标准化了 ABI。这（如果我过于简单化，请原谅我）可以保证来自任何 C 编译器或其他语言的调用者如何使用导出的符号。因此，为什么 GTK+ 与各种其他语言绑定 - 包括 GTKmm 中的 C++。恕我直言，后者是两全其美：GTK+ 完善的 API，但具有 C++ 的语言特性。
C++ 目前还没有正式的标准 ABI，不过一切还没有丢失，因为 A 团队正在努力解决它：https://isocpp.org/files/papers/n4028.pdf
Just a little elaboration on something hinted by Vlad: A major point in favour of C is that it makes interoptability between compilers or languages 'possible' (guaranteed), in that it standardises an ABI. This (pardon me if I'm oversimplifying) enables guarantees about how callers from any C compiler or other language can use exported symbols. Hence why GTK+ has bindings to various other languages - including C++ in GTKmm. The latter is the best of both worlds IMHO: the well-established API of GTK+ but with the language features of C++.
C++ as yet does not have an official standard ABI, though all is not yet lost, as the A-Team are working on it: https://isocpp.org/files/papers/n4028.pdf