5

What are the relevant practices for ensuring const-correctness when writing classes that serve as wrappers to other library (C style) APIs. I was in the process of writing a class (Renderer) that translates app specific render calls to corresponding OpenGL(and perhaps DirectX later) calls. This class doesn't actually have its own state that is modified by calls to, say, Renderer::applyTransform(const Matrix&), but is internally calling APIs that alter OpenGL's state. In this case, is marking such APIs as const the correct thing to do, or does the "modifies observable state" also extend to the OpenGL state that this class wraps, requiring me to make it non-cost?

This is similar to Const-correctness and hardware writes, but perhaps this is a more specific use-case.

4

3 に答える 3

3

非 const ポインターによってメンバー変数を取る C 関数を呼び出す場合、それらのラッパー関数はおそらく const であってはなりません。状態を監視するだけで変更しない場合は、メソッドを const にすることができます。C API が const-correct でなくても、必要に応じてメンバー変数で使用const_cast<>できます。mutable

セマンティクスの観点から考えてみてください。メソッドが世界の状態を変更しない場合は、const にします。それが世界の状態を変更する場合、変更された状態が変更をもたらすのは最適化のみであり、本質的なものではないキャッシュのようなものでない限り、おそらく const であってはなりません。

于 2013-03-20T03:52:16.360 に答える
2

それらを非にする必要がありますconstか？いいえ。

セマンティクスが有効な状態が変更されるというものである場合、それは良い考えでしょうか? おそらくそうですが、それは全体的な設計によって異なります。

于 2013-03-20T05:20:25.017 に答える
0

メソッドは単なる関数であり、this別の関数パラメーターです。任意のパラメータを へのポインタにすることができますconst。これは、対応する引数にのみ影響し、他の引数またはグローバル状態を変更する関数とは関係ありません。

そうです、constメソッドはグローバル状態を変更できますが、それは何も悪いことではありません。

于 2013-03-20T04:52:44.530 に答える