C++ gsl:：not_null是否会影响性能？

建议使用

gsl:：not_null

类型。如下列文件所述：

以帮助避免取消对nullptr错误的引用。通过 避免对nullptr进行冗余检查

通过在 源、实现者和工具可以提供更好的诊断，例如 通过静态分析查找某些类别的错误，并执行 优化，例如删除分支和空测试

（如果有兴趣，这是微软对

gsl:：not_null

：）的实现）

指南文档说，它通过“删除分支和空测试”来提高性能。但是，它也增加了开销，因为如果我想访问底层指针，将调用方法

operator->（）

和

operator*（）

（这不包括Microsoft实现在这些方法中的运行时检查开销）

---

鉴于无法保证方法内联，文档如何得出净性能增益为正的结论

但是，由于方法运算符->（）和运算符*（）

除此之外，这些函数是内联定义的，并且非常小，因此Optimizer将（很可能）内联扩展它们，这将完全消除潜在的开销

doc如何得出净绩效收益为正的结论

正如您所引用的，文档甚至没有确认相关的开销，因此这样的结论是微不足道的

---

如果你是指文件的作者是如何得出这样的结论的，那么只有那些作者知道。它的范围可能从“他们测量了它的影响”到“他们做出了一个假设”。

“如果方法内联没有得到保证，文档如何得出净性能增益为正的结论？”基准测试虽然不能保证函数调用会内联，大多数/所有编译器都会像这样内联包装器代码，因为它知道它应该是“零成本”抽象。。。如果您关心像这样的实现质量问题，您需要选择一个实现并进行实际测试。谁知道呢，也许你有一个特别糟糕的实现——我们当然不能告诉你。好吧，事实上，文档做出了一个理论上不能保证为真的假设。我认为写@t.niese是有道理的，只要你定义了违反合同的行为。