Loki是一个研究/概念验证之类的东西。Alexandrescu推动新的想法，其他人采用那些真实的世界。boost::shared_ptr也几乎是TR 1中的字面意思。

Loki是一个很好的库，涉及几个功能领域（模板元编程支持一些特定的应用程序：智能指针、单例、函数对象、范围保护等），而Boost是许多库的集合，这些库通常详尽地覆盖每个功能区域，并且针对可移植性（首先）进行了更高度的调整。
当10只鸟中有9只可以用同一块石头杀死时，许多人只是从boost开始，用第三方库填补空白。如果重叠的话，很难与boost竞争。因为你不会与boost有太多的重叠，人们会下载/安装boost来获得其他功能，所以除非你抓住了boost的薄弱环节--而且这个区别对项目很重要，否则他们也会“满足”于boost。
此外，Alexandrescu多次尝试将Loki包含在boost中，但一些关键的boost作者并不合作。我个人的观点是，他们希望更完整但用户友好性差得多的MPL拥有更多的“市场份额”：作为库和硬拷贝书籍的作者，这些书籍是唯一像样的文档（与大多数其他拥有优秀在线文档的boost库形成鲜明对比），他们在这方面做得很好。
如果有人被这种分析冒犯或不同意，我洗耳恭听。
极度参数化代码的另一个实际问题是，在不同开发人员/团队独立工作的大型项目中，他们通常会随意使用同一模板的不同示例化。这使得在这些子系统之间传递值变得更加困难：接收机可能需要：

• 被参数化（即模板化，因此是内联的，这会引入编译依赖性，并且在企业级系统中构建速度较慢）
• 为所有可能的示例化（例如，检查错误代码和预期/处理异常）
• 基于具有每个示例化的实现的抽象基本访问器，通过一些编译时到运行时的切换来工作），这损害了参数化的一些性能益处

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

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

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

作为一个经常使用Boost库，并且不止一次地查看Loki的人来说，最大的问题是文档的稀疏性。此外，Loki使用了一些C++模板中最粗糙的部分。令人兴奋的东西，但也相当令人生畏。

我曾经用Loki做过一个小工具（基本上是一个解释器），实际上我很喜欢它。我的同事们对这个库不太感兴趣，所以它的使用仍然局限于这个小的子项目。