Loki库实现了一些非常广泛使用的概念（智能指针、访问者、工厂等）。相关书籍《Modern C++ Design》经常被提及，但库本身并没有被广泛使用。这是为什么？
大多数开发人员似乎更喜欢 Boost。特别是，为什么人们经常决定使用 Boost 的智能指针而不是 Loki 的？
问问题
14564 次
6 回答
20
Loki 是一种研究/概念验证之类的东西。Alexandrescu 推动新的想法，其他人将这些想法用于现实世界。也boost::shared_ptr几乎在 TR1 中。
于 2010-02-27T16:54:35.097 回答
17
Loki 的缺点在于它是一个涉及多个功能领域的优秀库（模板元编程支持一些特定应用程序：智能指针、单例、函数对象、范围保护等），而 boost 是许多库的集合，通常详尽地涵盖每个功能领域并且对便携性进行了更高的调整（首先）。
当10只鸟中有9只可以用同一块石头杀死时，很多人只是从boost开始，填补了第三方图书馆的空白。如果重叠，很难与 boost 竞争。因为您不会与很多 boost 重叠，所以人们无论如何都会下载/安装 boost 以获得其他功能，所以除非您确定 boost 薄弱的领域 - 并且差异对项目很重要，他们会“解决” 那里也有提升。
此外，Alexandrescu 反复尝试让 Loki 加入 boost，而一些关键的 boost 作者只是不合作。我个人的观点是，他们希望更完整但用户友好性低得多的MPL拥有更多“市场份额”：作为图书馆的作者和作为唯一体面文档的硬拷贝书籍（与大多数其他推动力形成鲜明对比具有出色在线文档的图书馆），他们在这方面做得很好。
如果有人被这种分析冒犯和不同意，我会全神贯注。
极度参数化代码的另一个实际问题是，在不同开发人员/团队独立工作的大型项目中，他们通常会非常随意地使用相同模板的细微不同实例化。这使得在这些子系统之间传递值变得更加困难：接收器可能需要：
- 被参数化（即模板化，因此是内联的，这会在企业级系统中引入编译依赖和较慢的构建）
- 为所有可能的实例提供一些最小覆盖（例如检查错误代码和预期/处理异常）
- 通过一些编译时间到运行时间的切换，基于一个抽象的基础访问器，每个实例都有实现），这会损害参数化的一些性能优势
这一切皆有可能，但需要一位出色的程序员来驾驭地形。
于 2011-02-18T08:02:22.570 回答
12
你想使用一个下一个程序员会知道的库，并且将来会得到很好的支持——所以你选择一个主要的库。因为它是很多人使用它的主要库，所以它成为默认选择。
于 2010-02-27T16:51:56.523 回答
7
我实际上更喜欢 Loki 的做事方式，并且我自己为 Loki 贡献了一个装饰器模式，它现在位于跟踪器中，因为据我所知，该项目不再维护。
我使用 boost shared_pointer 只是因为它很快就会成为标准，我可能不喜欢这样一个事实，即我无法自定义它以完全按照我想要的方式运行，但我必须忍受它。
标准库的使用很重要，因为它使其他程序员可以维护代码。如果它是开源的，并且您想进行实验，请继续使用 Loki。没有人阻止你。
实际上，Windows Vista 使用了 Loki 的一些功能。
我猜他们没有使用智能指针和访问者的冗余实现。
于 2010-02-27T19:47:04.660 回答
4
作为一个使用过很多 Boost 库并且不止一次看过 Loki 的人来说，最大的问题是文档的稀疏性。此外，Loki 使用了一些 C++ 模板中最复杂的部分。令人兴奋的东西，但也相当令人生畏。
于 2010-02-27T16:54:03.600 回答
3
I used Loki once for a little tool (basically an interpreter) and actually liked it. My coworkers were less enthusiastic about the library, so its use remained constrained to this small sub-project.
于 2010-02-27T19:24:51.227 回答