Const正确性——C API垫片层

Const correctness -- C API shim layer

本文关键字：正确性 Const API 更新时间：2023-10-16

在编写作为其他库(C风格)api包装的类时，确保常量正确性的相关实践是什么?我正在编写一个类(Renderer)，将应用程序特定的渲染调用转换为相应的OpenGL(可能还有DirectX)调用。这个类实际上没有自己的状态，可以通过调用Renderer::applyTransform(const Matrix&)来修改，但是在内部调用api来改变OpenGL的状态。在这种情况下，是否将这样的api标记为const是正确的事情，或者"修改可观察状态"是否也扩展到该类包装的OpenGL状态，要求我使其非成本?

这类似于常量正确性和硬件写入，但这可能是一个更具体的用例。

如果您调用的C函数通过非const指针获取成员变量，则这些包装函数可能不应该是const。如果它们只观察状态而不修改它，你可以让你的方法const——即使C API不是const-correct，你也可以根据需要在你的成员变量上使用const_cast<>或mutable。

从语义的角度来考虑——如果一个方法不改变世界的状态，就把它设为const。如果它确实改变了世界的状态，它可能不应该是const，除非改变的状态类似于缓存，它只是导致改变的优化，而不是必要的东西。

是否要求它们非const ?没有。

如果语义是有效状态将被修改，这是一个好主意吗?可能是的，但这取决于你的整体设计。

方法只是一个函数，this只是另一个函数参数。任何形参都可以是指向const的指针，这只影响相应的实参，与函数修改任何其他实参或全局状态无关。

所以，是的，const方法可以修改全局状态，这没有错。