8

在用其他语言开发了几年之后，由于 ISO C++11 引入了一些不错的特性，我重新开始使用 C++。是否有任何库（基于 DirectX/OpenGL）在其公共 API（共享 ptrs、lambda 友好等）中使用这些新功能？

编辑：该库也可以处于 beta 状态，因为我不希望任何库在尚未完全发布的规范上能够商业化。

4

5 回答 5

4

从自述文件：

Magnum是用 C++11/C++14 和现代 OpenGL 编写的 2D/3D 图形引擎。它的目标是使用最新的 C++11/C++14 特性来简化底层图形开发和与 OpenGL 的交互，并抽象出特定于平台的问题。

于 2015-06-01T15:36:12.150 回答
1

没有什么可以阻止您使用例如。任何代码中的 lambdas、auto 和初始化列表。

Gtkmm 和亲戚（你可能喜欢Cairo C++ 绑定）有干净的 C++ 接口，允许你在你认为合适的时候使用 lambdas 和 autos。能够使用 lambda 作为信号处理程序以及在从 Gtk 智能指针初始化变量时使用 auto 非常有用。

此外，图形代码通常是应用程序的一小部分，而对于其他部分，您可以使用适当的 C++ 及其完整的标准库。

除此之外，还没有完全支持 C++11（Visual Studio 远远落后，g++ 的支持还没有完成），因此为 C++11 设计的库还没有出现。

没有什么能阻止你尝试和制作你自己的:)

于 2012-04-26T22:56:25.967 回答
1

据我所知，目前还没有完整的 C++11 编译器。G++ 非常接近，但还没有。我建议等一下。学习语言是有意义的（即使它不可用），但我认为尘埃落定需要几年时间。

据我所知，在任何图形库中几乎没有地方可以使用任何“高级”语言功能（甚至包括 c++03 中存在的所有内容）。试图充分利用硬件资源并不是使用“编程功夫”有意义的地方——你最终会担心其他事情，而 KISS 原则是优先考虑的。要么就是这样，要么你最终会陷入某种非常具体的破坏心灵的三角噩梦，其中 KISS 原则再次成为优先事项。

据我所知，因为单一语言而改变图形 API 是不值得的，因为多语言的可用性更重要。对于 OpenGL 尤其如此，但即使是 DirectX 也有一些“粉丝制作”的绑定。

目前，在开发在现有 3d API 之上运行的自定义框架时，您可以自由使用所需的任何功能。共享/弱指针在资源管理中很有用。但是，没有理由为此使用 C++11，因为功能在 boost 中可用。

- 编辑 -

据说Qt 5支持 C++11。从技术上讲，它是一个使用 OpenGL 的图形库...

于 2012-04-26T23:00:22.033 回答
1

最接近您想要的可能是SFML，它是一个非常干净的 OpenGL 对象包装器，它或多或少地始终使用现代 C++ 习语。

但是，它没有使用 C++11，而且它太大而无法移植（它包括声音、网络以及除图形之外的更多内容）。

我认为它可以作为 C++11 增量 API 更新的良好基础。

于 2012-04-26T23:03:38.677 回答
0

好吧，在 OpenGL 上不行，因为它是一个 C 兼容的 API。

就 DirectX 而言，他们当然不会到处更改 API，只为了在不需要时包含像 lambdas 这样的简洁语言功能。与标准的先前版本相比，C++11 编译器仍然不常用，因此创建一个只有一小部分开发人员可以使用的 API 将是非常愚蠢的。

当成千上万的人使用它时，更改您的 API 会产生广泛的影响。他们将 lambdas 添加到 API 函数中是非常不负责任的，只是因为它们整洁而有光泽。最重要的是，如果您关心实际使用它的人，那么您就不能在每个新版本中破坏您的 API。

EJDIT：

一开始我误解了这个问题。C++11 太新了，目前可能还没有对现有库的 API 更改，因为它会严重限制它们的用户群（据我所知，目前还没有功能齐全的 C++11 编译器，并且即使我们大多数人都不会使用它）。

正如一些评论者正确指出的那样，我最初的反应太狭窄了。您补充说测试版是可以接受的。我仍然不知道有任何库已经大幅修改了他们的 API 以包含 C++11 中的新功能，我之前的观点仍然成立。

更改 API 函数签名很危险，因为您破坏了向后兼容性。如果/当这些更改确实到来时，我希望它们是对 API 的补充，而不是修改。也许这里的某个人知道我不知道的对现有库的最新更改。

于 2012-04-26T22:42:44.240 回答