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

Question

在洛基库实现了一些使用非常广泛的概念(智能指针,访客,工厂等).经常提到相关的书"现代C++设计",但图书馆本身并没有被广泛使用.这是为什么？

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

Answer 1

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

Answer 2

Loki是一个很好的图书馆,涉及几个功能区域(模板元编程支持一些特定的应用程序:智能指针,单例,功能对象,范围保护等),而boost是许多库的集合,通常详尽地涵盖每个功能区域并且更加高度重视便携性(第一).

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

此外,Alexandrescu多次尝试将Loki纳入提升,一些关键的提升作者只是不合作.我个人的观点是,他们希望更完整但更不易用户的MPL拥有更多的"市场份额":作为图书馆的作者和硬拷贝书籍是唯一体面的文档(与大多数其他提升形成鲜明对比)有优秀在线文档的图书馆),他们做得很好.

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

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

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

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

Answer 3

您希望使用下一个程序员将​​要知道的库,并且将来会得到很好的支持 - 所以您选择了一个主要的库.因为它是一个主要的lib很多人使用它,所以它成为默认选择.

Answer 4

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