我有几个关于Loki库和新标准C11的问题。
我的第一个问题是关于LevelMutex库的功能。LevelMutex直接使用windows上的CRITICAL_SECTION和Linux中的pthread_mutex_t来实现功能。课程设计得非常好，但有一个问题仍然存在于我的脑海中。现在我们在新标准（std::mutex）中有了一个全新的 Package 器，是否值得用这个 Package 器替换依赖于平台的低级对象？如果不是，原因何在？我的观点是--我们可以在Loki中删除大量的编译器检查--我们可以保持Loki的最新版本，当标准库中发生更改时，所有更改都将推送到Loki--我们可以在Loki中使用std::mutex的例外。
我知道std::mutex只是平台互斥对象的 Package 器，异常也是系统特定错误的 Package 器，但仍然...同样的问题也适用于Threads.h中的功能。
我的第二个问题是关于Loki中实现的SmartPtr。您认为在我们有shared_ptr、unique_ptr等的情况下，是否值得使用此实现？如果是，为什么？如果没有，我认为重写一点LockingPtr实现以获得线程安全的shared_ptr是一个好主意？
我的最后一个问题是关于C11标准中新的std::thread功能。我正在考虑为这个特定的功能编写策略类，比如能够创建可接合线程或可分离线程。在您看来，std::thread的哪一部分值得创建策略？
提前感谢您的回答！
1条答案
按热度按时间cx6n0qe31#
这是一个广泛而有点主观的主题，我只能给予你我个人的建议。我不想谈细节，因为我认为退一步看大局很重要。
我通过使用新的C11标准和用标准库提供的任何东西替换其他库获得了一些很好的经验。而“我”也指我工作的地方的代码库（一家拥有超过100.000名员工的公司的一个部门）。
像Loki或Boost这样的库在探索新的领域和推动C向前发展方面做得很好，对于Boost来说，它实际上是一个明确的目标，即创建最终将被标准化的新组件。
虽然
std::shared_ptr、std::thread和std::mutex的标准化版本可能缺少一些细节，但它们设计得很好，可移植性很好，而且它们是编译器附带的标准库的一部分，经过了很好的测试！这些都是对他们有利的要点。它还有助于使您的代码面向未来，更容易维护，更容易让新人加入。因此，我的建议是：尽可能多地使用C++11（包括标准库）所提供的一切。如果有必要，只使用Loki、Boost或其他库，但要保持开放的心态，关注它们的发展。