我应该在新的 C++ 项目中使用指南支持库 (GSL) 吗？ [关闭]答案

【问题标题】：Should I use the Guidelines Support Library (GSL) in a new C++ project? [closed]我应该在新的 C++ 项目中使用指南支持库 (GSL) 吗？ [关闭]
【发布时间】：2019-01-16 10:37:29
【问题描述】：

在新的 C++ 项目中支持和反对使用指南支持库 (GSL) 的优缺点是什么？我发现那里的一些结构非常有吸引力，但有点害怕包含和依赖这样一个基础库。

【问题讨论】：

除非他们正确实现检查迭代器，否则它几乎没用......
这要么过于宽泛，要么基于观点。它是一个和其他库一样的库，当你认为它有帮助时使用它，如果你不喜欢依赖就不要使用它
您是否愿意我将问题重新表述为“使用 GSL 的优缺点是什么？”。
不确定，我投票决定关闭，但同时我认为这是一个有趣的问题。有时这只是措辞的问题，也许是“当我不严格遵守指南时，我可以使用 GSL，反之亦然吗？”在导致相同答案的同时更客观

标签： c++ cpp-core-guidelines guideline-support-library

【解决方案1】：

GSL 只是 C++ 核心指南的支持库。如果您使用 GSL，那么这些核心指南应该是您应用于代码的指南（不是 Google 或任何其他在线找到的指南）。您不需要 GSL 作为核心指南，也不需要使用 GSL 中的所有内容。就我个人而言，我已经开始将它用于index 和not_null 之类的简单位。

GSL 并不完美，有很多可以/应该添加的东西，它不会妨碍我做一些疯狂的事情，但它有助于为我正在做的事情添加一个框架/某种验证。它还消除了index 的签名/未签名问题。

我建议在新项目中使用它，因为它的运行时开销应该为空，但这只是个人喜好问题。如果您的项目有很多新开发人员（或蹒跚学步的孩子），那么可以考虑帮助他们成长。

【讨论】：

GSL 与 boost 有什么关系？是否可以预期 GSL 的东西会在某个时候进入标准库？
我希望gsl::index 能做到，而且我认为有些位也足够合理，例如not_null。 span 已经走上了包容之路 (AFAIK)。
实际上，我认为这是反对使用它的论据，艰难我刚刚了解到它只是标题，再次成为使用它的有力论据......我认为时间会告诉我们它将如何演变
语言内部发生的事情？之后，只是替换命名空间的问题，没什么大不了的。但总的来说，它在使用方面比 Boost 轻得多，它只是为了支持，而不是为了基础的东西。
我的意思是，如果最终它进入标准，那么除非我迫切需要它，否则我现在不会考虑它，但也许我应该在做出这样不合格的陈述之前仔细看看;)