c++ - Loki 和 C++11

Question

我有几个关于 Loki 库和新标准 C++11 的问题。

我的第一个问题是关于 LevelMutex库的功能。 LevelMutex直接使用 CRITICAL_SECTION在 window 上和一个pthread_mutex_t在Linux为了实现功能。类(class)非常好设计，但一个问题仍然在我脑海中。现在我们有了一个全新的包装器在新标准(std::mutex)中是否值得更换低级对象平台依赖于这个吗？如果不是，为什么？我的观点是- 我们可以删除 Loki 中的大量编译器检查- 我们可以保持 Loki 的最新版本，当标准库发生变化时，所有更改都会推送到 Loki- 我们可以使用 std::mutex 的异常(exception)情况在洛基。

我知道 std::mutex只是平台互斥对象的包装器，并且异常也是系统特定错误的包装器，但仍然......同样的问题适用于 Threads.h 中的功能。 .

我的第二个问题是关于 SmartPtr在 Loki 中实现。考虑到我们有 shared_ptr , unique_ptr ， ETC ？如果是，为什么？如果没有，我认为重写是个好主意LockingPtr 实现一点点以获得线程安全的 shared_ptr ？

我的最后一个问题是关于新的 std::thread C++11 标准中的功能。我正在考虑为这个特定的功能编写策略类，比如具有创建可连接线程或可分离线程的能力。在您看来，std::thread 的哪一部分？制定一项政策会很有趣吗？

提前感谢您的回答!

Answer 1

这是一个宽泛且有些主观的话题，我只能给你我个人的建议。我不会详细介绍，因为我认为退后一步并从大局着眼很重要。

通过使用新的 C++11 标准并用标准库提供的任何内容替换其他库，我获得了一些很好的经验。我所说的“我”还指我工作地点的代码库(一家拥有超过 100,000 名员工的公司的一个部门)。

像 Loki 或 Boost 这样的库在探索新领域和插入 C++ 发展方面做得非常好，对于 Boost 来说，它实际上是一个明确的目标，即创建最终将被标准化的新组件。

虽然 std::shared_ptr、std::thread 和 std::mutex 的标准化版本可能缺少一些细节，但它们设计精良，可移植，并且鉴于它们是编译器随附的标准库的一部分，因此它们经过了很好的测试!这些是对他们有利的重要观点。它还有助于使您的代码经得起 future 考验并更易于维护，新人更容易上手。

因此，我的建议是:尽可能多地使用 C++11(包括标准库)必须提供的一切。仅在必要时使用 Loki、Boost 或其他库，但要保持开放的心态关注它们的发展。