为什么Loki库没有被更广泛地使用？

Question

Loki库实现了一些非常广泛使用的概念（智能指针，访问者，工厂等）。经常提到相关的书“现代C ++设计”，但图书馆本身并没有被广泛使用。那是为什么？

大多数开发人员似乎更喜欢Boost。特别是，为什么人们经常决定使用Boost的智能指针而不是Loki？

Answer 1

Loki是一种研究/概念验证的东西。 Alexandrescu推出新想法，其他人采用那些现实世界。此外boost::shared_ptr几乎完全在TR1中。

Answer 2

Loki在一个很好的图书馆中遇到了几个功能区域（模板元编程支持一些特定的应用程序：智能指针，单例，功能对象，范围保护等），而boost是许多库的集合，通常详尽地覆盖每个功能区域都更加适合便携性（第一）。

当用同一块石头杀死10只中的9只鸟时，许多人只是从提升开始并填补第三方图书馆的空白。如果重叠，很难与提升竞争。因为你不会与大部分的提升重叠，人们无论如何都会下载/安装提升以获得其他功能，所以除非你指出一个提升弱的区域 - 并且差异对项目很重要，他们将“解决” “也是为了提升。

此外，Alexandrescu多次尝试将Loki纳入提升，而一些关键的提升作者只是不合作。我个人的观点是，他们希望更完整但更不易用户MPL获得更多“市场份额”：作为图书馆的作者和硬拷贝书籍是唯一体面的文件（形成鲜明对比）与大多数其他具有优秀在线文档的boost库一样，它们在这方面做得很好。

如果有人对此分析感到冒犯并且不同意，我会全力以赴。

极其参数化代码的另一个实际问题是，在不同开发人员/团队独立工作的大型项目中，他们通常最终会使用相同模板的微妙不同的实例。这使得在这些子系统之间传递值变得更加困难：接收器可能需要：

• 进行参数化（即模板化，因此内联，这会在企业级系统中引入编译依赖性和较慢的构建）。
• 为所有可能的实例化提供一些最小的覆盖范围（例如，检查错误代码和期望/处理异常）
• 在一些编译时间内完成基于抽象基本访问器的运行时切换以及每个实例化的实现，这会损害参数化的一些性能优势

这一切都是可能的，但需要一个优秀的程序员来导航地形。

Answer 3

你想要使用下一个程序员将​​要知道的库，并且将来会得到很好的支持 - 所以你选择了一个主要的库。 因为很多人都使用它，所以它成为默认选择。

Answer 4

我实际上更喜欢Loki的做事方式，而且我自己也为Loki贡献了一个装饰模式，现在它位于跟踪器中，因为据我所知，的项目已不再维护。
我使用boost shared_pointer只是因为它很快就会成为标准，我可能不喜欢这样一个事实：我无法自定义它以完全按照我希望的方式行事，但我必须忍受它。
标准库的使用很重要，因为它可以保持代码可由其他程序员维护。如果它是开源的，你想要实验继续使用Loki。没有人阻止你 实际上Windows Vista使用了Loki的一些功能 我猜他们没有使用智能指针和访问者的冗余实现。

Answer 5

作为一个使用Boost库的人，并且不止一次地看过Loki，最大的问题是文档的稀疏性。此外，Loki使用了一些最繁琐的C ++模板。令人兴奋的东西，但也相当令人生畏。

Answer 6

我曾经使用Loki作为一个小工具（基本上是一个翻译）并且实际上喜欢它。我的同事对图书馆的热情不高，所以它的使用仍然受限于这个小的子项目。