在编写用作其他库（C 风格）API 的包装器的类时，确保 const 正确性的相关做法是什么。我正在编写一个类（Renderer），它将应用程序特定的渲染调用转换为相应的 OpenGL（可能还有 DirectX）调用。这个类实际上并没有自己的状态，它通过调用 Renderer::applyTransform(const Matrix&) 来修改，而是在内部调用改变 OpenGL 状态的 API。在这种情况下，将此类 API 标记为 const 是正确的做法，还是“修改可观察状态”也扩展到此类包装的 OpenGL 状态，要求我使其成为非成本？
这类似于Const-correctness 和 hardware writes，但也许这是一个更具体的用例。
如果您正在调用通过非常量指针获取成员变量的 C 函数，那么这些包装函数可能不应该是 const。如果他们只是观察状态而不修改它，您可以使您的方法 const ——即使 C API 不是 const 正确的，您也可以根据需要使用const_cast<>或mutable在您的成员变量上。
从语义的角度考虑它——如果一个方法不改变世界的状态，就让它成为常量。如果它确实改变了世界的状态，它可能不应该是 const，除非改变的状态类似于缓存，它只是导致改变的优化而不是必要的东西。
您是否需要使它们成为非const？不。
如果语义是要修改有效状态，这会是一个好主意吗？可能是的，但这取决于您的整体设计。
方法只是一个函数，this只是另一个函数参数。任何参数都可以是指向 的指针const，这只影响相应的参数，与修改任何其他参数或全局状态的函数无关。
所以是的，一个const方法可以修改全局状态，这没有错。