为什么 Loki 库没有得到更广泛的使用？
Loki 库实现了一些非常广泛使用的概念（智能指针、访客、工厂等）。相关书籍《Modern C++ Design》经常被提及，但该库本身并未得到广泛使用。这是为什么？
大多数开发人员似乎更喜欢 Boost。特别是，为什么人们经常决定使用 Boost 的智能指针而不是 Loki 的？
The Loki library implements some very widely used concepts (smart pointer, visitor, factory, etc.). The associated book "Modern C++ Design" is often mentioned, but the library itself is not widely used. Why is that?
Most developers seem to prefer Boost. In particular, why do people often decide to use Boost's smart pointers rather than Loki's?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
Loki 是一种研究/概念验证之类的东西。亚历山德雷斯库提出新的想法，其他人将这些想法应用于现实世界。而且
boost::shared_ptr几乎在 TR1 中。Loki is a research/proof-of-concept sort of thing. Alexandrescu pushes new ideas, other people adopt those for real world. Also
boost::shared_ptris almost literally in TR1.Loki 的缺点是它是一个涉及多个功能领域的优秀库（模板元编程支持一些特定的应用程序：智能指针、单例、函数对象、范围保护等），而 boost 是许多库的集合，通常详尽地涵盖每个功能领域并且对可移植性进行了高度调整（首先）。
当同一块石头可以杀死十分之九的鸟时，许多人就开始使用Boost并用第三方库来填补空白。如果重叠，就很难与Boost竞争。因为你不会与太多的 boost 重叠，所以人们无论如何都会下载/安装 boost 以获得其他功能，所以除非你确定 boost 薄弱的领域 - 并且差异对项目来说很重要，否则他们会“解决” ” 那里也有提升。
此外，Alexandrescu 多次尝试将 Loki 纳入 boost，但一些关键的 boost 作者并不合作。我个人的观点是，他们想要更完整但不太用户友好的 MPL拥有更多的“市场份额”：作为图书馆和硬拷贝书籍的作者，这是唯一体面的文档（与大多数其他拥有优秀在线文档的 boost 库形成鲜明对比），他们在这方面做得很好。
如果有人被冒犯或不同意这种分析，我会洗耳恭听。
高度参数化代码的另一个实际问题是，在不同开发人员/团队独立工作的大型项目中，他们通常最终会非常随意地使用同一模板的细微不同的实例化。这使得在这些子系统之间传递值变得更加困难：接收器可能需要：
这都是可能的，但它需要一位优秀的程序员来驾驭地形。
Loki's suffers from being a good library touching on several functional areas (template metaprogamming support with a few specific applications: smart pointers, singletons, function objects, scope guards etc.), whereas boost is a collection of many libraries typically exhaustively covering each functional area and much more highly tuned for portability (first).
When 9 birds out of 10 can be killed with the same stone, many people just start with boost and fill in the gaps with third party libraries. It's very hard to compete with boost if you overlap. Because you won't overlap with much of boost, people will download/install boost anyway to get the other functionality, so unless you nail an area that boost is weak at - and the difference is significant to the project, they'll "settle" for boost there too.
Further, Alexandrescu made repeated attempts to get Loki included in boost, and some of the key boost authors just weren't cooperative. My personal view is that they want the more complete but much less user-friendly MPL to have more "market share": as authors of the library and the hard-copy books that are the only decent documentation (in stark contrast with most other boost libraries which have excellent online documentation), they do quite well out of this.
If anyone is offended by and disagrees with this analysis, I'm all ears.
Another practical issue with extremely parameterised code is that in large projects where different developers/teams work independently, they'll often end up using subtly different instantiations of the same template pretty arbitrarily. This makes it harder to pass values between those subsystems: the receiver may need to:
This is all possible, but it takes a great programmer to navigate the terrain.
您想要使用下一个程序员会知道的库，并且将来会得到很好的支持 - 所以您选择一个主要的库。
因为它是一个主要的库，很多人都使用它，所以它成为默认选择。
You want to use a library that the next programmer is going to know and that is going to be well supported in the future - so you pick a major lib.
Because it's a major lib lots of people use it, so it becomes the default choice.
实际上，我更喜欢 Loki 的做事方式，并且我自己为 Loki 贡献了一个装饰器模式，该模式现在位于跟踪器中，因为据我所知，该项目不再维护。
我使用 boost shared_pointer 只是因为它很快就会成为标准，我可能不喜欢这样的事实：我无法自定义它以使其完全按照我希望的方式运行，但我必须忍受它。
标准库的使用很重要，因为它使其他程序员可以维护代码。如果它是开源的并且您想尝试，请继续使用 Loki。没有人能阻止你。
实际上 Windows Vista 使用了 Loki 的一些功能。
我猜他们没有使用智能指针和访问者的冗余实现。
I actually prefer Loki's way of doing things and I have contributed to Loki myself a Decorator pattern which now sits in the tracker because the project as far as I know is no longer maintained.
I use boost shared_pointer just because it will be the standard very soon, I may dislike the fact that I can't customize it to act exactly the way I want it to act but I have to live with it.
Usage of the standard library is important as it keeps the code maintainable by other programmers. If it's open source and you want to experiment go ahead and use Loki. No one is stopping you.
Actually Windows Vista uses some of Loki's features.
I am guessing they are not using the redundant implementations of smart pointers and visitors.
作为一个使用过相当多的 Boost 库并且不止一次查看 Loki 的人来说，最大的问题是文档的稀疏性。此外，Loki 使用了 C++ 模板中一些最复杂的部分。令人兴奋的事情，但也相当令人畏惧。
Speaking as someone who's used quite a bit of the Boost library, and also looked at Loki more than once, the biggest problem was the sparsity of documentation. Also, Loki uses some of the hairiest bits of C++ templates. Exciting stuff, but also rather daunting.
我曾经使用 Loki 作为一个小工具（基本上是一个解释器），并且非常喜欢它。我的同事对图书馆不太热衷，因此它的使用仍然仅限于这个小子项目。
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.