我为我们公司的团队购买了这本书，也许是为了提高我们的设计技能并最终拥有更好的编程实践。当我阅读它时，我发现，大多数情况下，一组可以与模板一起使用的漂亮技巧，并且不确定是否值得 - 并且无害 - 将其合并到我们的代码中，从而引入代码复杂性/可读性和不可维护性.
我想从追随者那里了解一下，你从那本书中使用了什么？什么与专业软件开发相关和重要，应该避免什么？
一般认为这本书以及它如何适应大型系统的软件开发（在同一方面，我喜欢 John Lakos 的书）？
什么是亚历山大效应？
【问题讨论】：
标签： c++ design-patterns templates
在标准模板使用之外，我发现有关通用 C++ 编程的信息中最有用的操作是使用模板为无效代码场景创建编译时错误的能力。一旦你掌握了它的窍门，你就可以非常有效地将一类运行时错误转化为编译时错误。
我在工作中取得了很大的成功。当然，它会产生完全不可读的消息，我的同事偶尔会过来问“这到底是什么？”。但每次它都是一个错误，他们无法编译它。我还大量评论了特定的错误，希望它是可以理解的。
【讨论】：
大约在 2005 年左右，我深入研究了表达式模板和各种编译时技巧，用于制作非常易于使用的库，例如嵌入在 C++ 中的内部特定领域语言。特别是一个相当完整的嵌入式 SQL 东西，类似于后来在 .NET 上作为 Linq 出现的东西。
对于用户来说，这很好。但是对于除了我之外的任何其他人试图维护它，它呈现出一个非常陡峭的学习曲线。这就是问题所在；像任何“聪明”的技术一样，它减少了可以维护它的人。
这对于广泛使用的类库来说很好，普通用户永远不需要了解它的内容。但是对于特定团队拥有的“内部”库，他们可能都需要能够对其进行修补或明智地扩展它。根据我的经验，C++ 模板更神秘的可能性似乎排除了这一点。
虽然很有趣。
【讨论】：
如果您的公司/项目允许提升。这本书将帮助你发现一些提升魔法，只是为了你自己的满足。
如果您的公司/项目不允许提升。这本书将是一个很好的指南，可以重新创建一些你最需要的 boost 部分，比如 boost::function。
我相信在每个项目中都有某种实用模块。通过借用一些书籍建议的模式和 SFINAE 技巧，这样的书将帮助您使您的“实用程序”更加通用和安全。
本书的大部分内容将展示您如何重新思考一些 GOF 设计模式，通过静态改变运行时多态性。
【讨论】：
【讨论】：
对我来说，这更像是一次开阔视野的经历。我通读了这本书，不断地学习细节和技巧，其中一些我以后会用到。但最重要的部分是，本书一直在讨论大写 D 的设计（D 语言没有双关语）。
关于智能指针的章节将我的“提供所有可能的功能”的心态转变为更保守的心态：考虑一下您提供的内容，是否值得？它怎么能破解密码？它会帮助用户吗？它会通过创建微妙的陷阱使代码变得脆弱吗？
基于策略的设计部分应该让您在设计您的类是否可以/应该更好地划分为更小的正交单元时有所作为。虽然在大多数情况下，我并没有结束划分所有这些策略类，但代码通常会变得更干净，因为不同的正交部分变得更少纠缠。
哦，作为 Earwicker，我的第一反应是实现真正加速部分开发的花哨的东西，但话又说回来，在我工作的小公司中，我是唯一能够维护它的人，这确实是一个问题。不要过度。调试和维护所需的大脑是开发所需的两倍。
【讨论】：
恕我直言，阅读（并理解！）本书的第一章很有用（我相信它甚至可以免费在线获得）。本书的其余部分几乎描述了 Loki 库的内部结构，我并不真正推荐它。
【讨论】：
当我说使用现代 C++ 设计的东西时，我确实经历了一些粗鲁的反应。首先，WTF cmets。紧随其后的是“不要太聪明”的cmets。然后，更好地理解这些想法。然后，最后，接受这些想法，使其成为通用词汇的一部分。
请确保将这本书的多份副本放在手边。理想情况下，为每个开发人员购买一份副本。此外，在这些东西成为开发人员常用的词汇之前，请在您的 cmets 中引用模式/成语和相关页面。
【讨论】：
我没有使用 Loki，但我在之前的工作中积极使用了 boost。 Boost 实现了这本好书中的许多想法；
本书中的内容不适合在业务逻辑中使用，它们应该在库（Boost、Loki、您自己的东西）和业务逻辑中使用的库中实现。这是“在代码中使用这个技巧”或“在大多数代码中使用这个技巧并使用漂亮的库来实现分离的库”（例如 boost::bind - 丑陋的实现但使用起来很好 - 但你几乎从未见过这个实现）”
这本书还展示了强大的 C++ 元编程和良好的大脑训练。
【讨论】：