私は現在、私はその機能の欠点であるものgl::CreateShader(...)名前空間glのOpenGL関数の欠点は何ですか？
のようにそれらを使用することができるような場所のようなオプションがnamespace gl 内のすべての関数ポインタがある、OpenGLの機能をロードするために
をglLoadGenを使用していますか？ ？
thoes gl **関数またはマクロでグローバルな名前空間を汚染しません。 しかし、いくつかの潜在的な短所があります...
普遍的に使用されているC言語バインディングの命名規則に従わなくなる可能性が高いためです。名前空間全体の問題は、定数の先頭にGL_を、関数の先頭にglを付けることで、言語にとらわれない方法ですでに解決されました。
ここで必要なことは自由ですが、CやC++などの言語のグローバル名前空間は、リンク先のライブラリによって既に汚染されています。たとえば、WindowsではGL 1.1のすべての関数が名前の標準C言語バインディングと一緒に置かれています。これは、プラットフォームのOpenGLヘッダーをインクルードすることによって得られる約400の関数のセットです。
非C言語への様々なバインディングを考慮して、私はこの普遍的な用語を「普遍的な」と呼ぶことを躊躇します。 LWJGLは各OpenGLのバージョンと拡張機能に独自の擬似名前空間を与えます。 OpenTKはOpenGLを 'GL'クラスに置きますが、冗長化される' gl'と 'GL_'接頭辞を削除します。 C＃の規則に従ってOpenGLの列挙子の名前を変更することさえできます。 OpenGLを言語にバインドする方法がたくさんあることを考えると、なぜC++ *はCのリードに従わなければならないのですか？ –
@NicolBolas：間違ってはいけません。私は、多くの多くの言語バインディングがこの規約を廃止していることをよく認識しています。私のここでのポイントは、実際にはCやC++の 'gl/gl.h'をインクルードすることで、元の' gl * '規約で多くの関数をドラッグすることになります。すべてをそれ自身の名前空間に分離することによる意図が単純さであった場合、この状況では逆のことが達成される。独自のヘッダーを記述し、これを避けるためにソフトウェアのどの部分もプラットフォームヘッダーを含まないようにする必要があります。 –
"*これを避けるには、独自のヘッダーを記述し、ソフトウェアのどの部分もプラットフォームヘッダーを含まないようにする必要があります。 glLoadGenにその機能を書き込んだときに、私が何かを説明したものです*。それはOpenGLローダーについては非常によくあることです。事実上それらの全てが 'gl/gl.h'を手作業で含めるのを防ぎます。もしあなたがそれらのヘッダを含む前に*ヘッダをインクルードしようとすると動作しません。 GLEWのヘッダーでさえそうです。この問題は既に説明されています。 'wgl.h '問題さえ。 –
[この質問]（https://stackoverflow.com/questions/6670738/is-it-a-good-ide-to-wrap-an-include-in-a-namespace-block）は関連しています。 – CoryKramer
このオプションを使用する理由はわかりません。毎回余分な '::'をタイプする必要があり、GLコードを他のソースから直接コピー＆ペーストすることはできません。このオプションはグローバルな名前空間を汚染しないので良いと言いますが、すべての名前に適切な接頭辞が付いていれば汚染は問題にはなりません。 – HolyBlackCat
@CoryKramer関連していますが、glLoadGenとは異なります（オプションによって異なります）。 –