我一直在阅读 Alexandrescu 的书 Modern C++ design ，他使用的技术给我留下了深刻的印象，因此我想将Loki 库添加到我的应用程序中。
然而，经过进一步调查，我发现我已经在使用的 boost 提供了许多类似的功能（虽然不是全部，例如，我在 boost 中找不到单例）
由于基于策略的设计和仿函数，我最感兴趣的是使用 loki。
对我来说，boost和loki各有利弊。我对 loki 的主要担忧是糟糕的文档（图书馆不再与书绑定），但在我看来，loki 在某些领域比 boost 更强大和灵活（我可能在那个方面错了）
在选择将 boost 或 loki 用于仿函数和策略之前，我想知道在现实生活中使用它们的人的意见。
有时东西在纸上看起来非常好，但当你真正使用它们时会有一些缺点:)
Alexandrescu 有非常有趣的想法（类型列表、基于策略的类模板等），但其中很多都在 boost 中得到了改进，并在更广泛的编译器中进行了可移植性和正确性的测试。
仅出于这些原因，我建议尽可能选择 boost。也就是说，现代 C++ 设计仍然对 C++ 的灵活性提供了很多洞察力，并深入了解了一个人的思想（一个非常好的思想）以解决许多常见的编程问题。
例如，基于策略的智能指针是一个非常巧妙的想法，但我们可以找到为什么 boost 作者选择不以这种方式实现 shared_ptr 和 scoped_ptr ：
A. 参数化不鼓励用户。shared_ptr 模板经过精心设计，无需大量参数化即可满足常见需求。有一天，可能会发明一种高度可配置的智能指针，它也非常易于使用且很难误用。在此之前，shared_ptr 是各种应用程序的首选智能指针。（那些对基于策略的智能指针感兴趣的人应该阅读 Andrei Alexandrescu 的 Modern C++ Design。）
如果您确实需要各种各样的智能指针，并且您和您的团队习惯于广泛使用模板参数化，那么实现智能指针的基于策略的方法可能适合您。但是，scoped_ptr 和 shared_ptr（连同weak_ptr）往往会非常彻底地完成这项工作。策略类的组合行为可能更适合用于有多种有用组合的事物。
尽管如此，Alexandrescu 仍然有一些有趣的提议没有解决。例如，在编译器更好地实现移动构造函数或直到我们可以使用 C++0x 中的右值引用之前，MOJO仍然非常有用。他对实现内存分配器也有一些非常有趣的想法。
至于这个问题，我们在商业项目中使用了 mojo 所需的部分 Loki，但在适当的时候大多会增强。
可能要考虑的一件事是，boost 库在接受期间必须经过同行评审过程。当然，在那之后，我相信对发生的变化几乎没有监督，但至少在它们被接受之前会有一些审查。洛基只是一个人的愿景。当然，Alexandrescu 相当不错，但仍然......这都是他的想法，没有比这更进一步的评论了。
我在整个 C++ 环境中使用 Boost，就像标准库的扩展（使用 VC9 和 VC10）。
我不会在所有项目中使用它。
我在个人项目（主要是游戏）中使用它，我可以完全控制依赖关系。
我在一个大型游戏项目中使用 boost::function （以及来自 boost 的其他几个库）。
Loki 也很好，但我觉得没有必要。我认为我正在考虑使用的库的唯一部分是单例，但我正在使用目前足够好的自定义库。
C++0x 是我用于快速函数对象的。