最新のライブラリがOOPを使用しない理由

20

私は初心者レベルのC ++プログラマですが、言語の概念はかなりよく理解しています。SDLやOpenGLなどの外部C ++ライブラリを学習し始めたとき、驚いたことに、C ++の概念をまったく使用していないことがわかりました。

たとえば、SDLもOpenGLもクラスや例外を使用せず、関数とエラーコードを優先します。OpenGLでは、glVertex2fのような関数を見てきました。これは、入力として2つのfloat変数を取り、おそらくテンプレートとしてはより良いでしょう。さらに、これらのライブラリは時々marcosを使用しますが、マクロの使用が悪いことは一般的な合意のようです。

全体として、C ++スタイルよりもCスタイルで記述されているようです。しかし、それらはまったく互換性のない言語ですよね？

問題は、なぜ現代のライブラリは、それが書かれている言語の利点を使用しないのかということです。

— セージ
ソース

1

ティモはあなたの質問によく答えたと思います。他の理由（他のライブラリの場合）は、Cで作成されてから移植されたライブラリである可能性があります。または、C開発者が作成しました。

— ジャンヌ・ボヤルスキー

5

それとは別に、OpenGLも、若いという意味で「近代的」でも、少なくとも派手な新しい機能を採用できるという意味でもありません。両方とも長い歴史（OpenGL 1.1：1997; SDL：1998）と後方互換性の制約があります。

1

ちょうどそう言われています：DirectXははるかに客観的です（かなり低レベルの場合もあります）。

— cHao

1

stlやBoostなどのネイティブC ++ライブラリは、くだらない、時代遅れの、役に立たないOOPの概念も使用しません。

— SKロジック

5

ここでのあなたの誤解は、SDLとOpenGLが多くの「モダンライブラリ」の代表であると思います。たとえば、非常に人気のあるQtライブラリは完全にオブジェクト指向です。あなたの質問のタイトルは、「SDLとOpenGLがOOPを使用しないのはなぜですか？」

— ドックブラウン

31

OpenGLとSDLはどちらもCライブラリであり、Cインターフェースを世界に公開しています（ほとんどの言語はCとインターフェースできますが、必ずしもC ++とインターフェースする必要はありません）。したがって、Cが提供する手続き型インターフェースと、データ構造を宣言および使用するCの方法に制限されています。

Cインターフェースが提供する「他の言語とのインターフェース」の側面に加えて、Cは一般にC ++よりも移植性が高い傾向があるため、ライブラリのコードのプラットフォームに依存しない部分を取得しやすくなりますこれらは別のOSまたはハードウェアアーキテクチャで動作します。そこにあるほとんどすべてのプラットフォームにはまともなCコンパイラがありますが、C ++コンパイラを制限したり、あまり良くないものもあります。

CとC ++は非常に異なる言語ですが、実際には「互換性がない」わけではありません。実際、C ++はCのスーパーセットです。する。

— ティモ・グッシュ
ソース

ああなるほど。それでは、次の質問です。たとえば、OpenGLと同じくらい効果的なC ++のグラフィックライブラリはありますか。または、C ++のすべての利点を使用し、リソースを適切に管理するOpenGLのラッパーでしょうか？APIはずっときれいに見え、メモリ/ CPUのオーバーヘッドが高すぎるとは思いません。

— Saage

効果的または効率的ですか？どちらにしても、SDLまたはOpenGLのいずれかのC ++ラッパーを見つけるのはかなり簡単です。Googleが簡単にこのOpenGLのラッパーを作成しました：oglplus.org-それがどれほど良いか、私はそれを使っていません。

— ティモゲーシュ

1

ええ、OpenGLをより多くのC ++のインターフェースでラップしようとするプロジェクトがかなりあります（多くの機能を控え、ほとんどオーバーロードなどを追加しますが、自分でも持っています）。私の印象では、ほとんどの場合、多くの荷物が追加されるため、純粋なOpenGLスニペットを翻訳するのが難しくなり、標準的な最適化を適用するのが難しくなります（データ指向デザインを調べ、一部のゲーム開発者はそれを誓います）。しかし、決してそれであなたを思いとどまらせないでください。または、必要最低限のグラフィックスAPIだけでなく、ゲームエンジン全体（IrrlichtやOgreなど）を使用する方が幸運かもしれません。

さて、私は私が探していたすべての答えを持っていると思います。みんな、ありがとう！

— Saage

また、グラフィックスハードウェアはクラスの計算や計算を実行しないことに注意してください。あなたが持っているfloat3のは、すべてのハードウェアがフロートの配列に関係しているからです。「クラス」構造（ベクトルが2、3、または4つの浮動小数点であるという概念）はすべて、メモリのヒープにアクセスするようにカードに指示する方法に暗黙的です。グラフィックをプログラミングするときにクラスで考えてみるのはいいかもしれませんが、私の意見では、その種の作業はハードウェアに十分に近いため、実装の汚れた詳細を抽象化するのを助けるよりも面倒です。

— デビッドカウデン

10

「ライブラリの作成」と「APIの外部公開」を混同していると思います。あなたが言及したライブラリについてはあまり詳しくありません（それらは内部でCで書かれているかもしれません）が、私は他の多くの人が、すべての種類の派手なOOPプラクティス/パターンを完全に利用したC ++ライブラリ/フレームワークを書いたことを知っています、それでもCスタイルのAPIを外部に公開しました。

CとC ++はまったく異なるシステムではありません。C ++はCの上に構築され、a）Cコードを簡単に消費でき、b）CスタイルのAPIを完全に提供できます。
Cインターフェースの利点は、世界中で非常に簡単に消費できることです。ほぼすべての言語（python、java、c＃、php ...）からC APIを使用できるようにする相互運用層があります。C++インターフェースは.......から消費される可能性があります。異なるコンパイラ、同じコンパイラの異なるバージョンにより問題が発生します）

過去に、作業中のプロジェクトの1つの実験として、C ++ DLLから「OO」インターフェースを公開することにしました。内部の詳細を隠し、他の多くのものを避けるために、私はほとんどWindows COM（コンポーネントオブジェクトモデル）を再発明することになりました。そのプロジェクトの後、a）OOPインターフェースを公開し、b）私が遭遇したすべての問題を処理し、c）多くの人から消費できるほど十分に標準的であるため、COMは人々がそれほど悪くないことに気付きました他の言語。

しかし、COMにはまだ手荷物がないわけではありません。多くの場合、通常のプランCスタイルのAPIの方がはるかに優れた代替手段です。

— DXM
ソース

7

OpenGLとSDLはどちらもCライブラリであり、C ++ライブラリではありません。C ++から使用できますが、Cで書かれており、C APIがあります（他の言語からもアクセスできます。C++はFFI経由でアクセスするのが面倒です）。見ていブーストを汎用の大型アレイ（および一部の専門）C ++ライブラリとのためにSFML C ++マルチメディアライブラリの。

3

特にOpenGLについて言えば、OpenGLはもともとAPIのスタックの一部でした-OpenGLは、C（またはFortran）からアクセス可能な低レベルのパフォーマンス指向のAPIを提供し、OpenInventorは設計された高レベルのオブジェクト指向APIを提供しましたC ++から使用し、高レベルのシーングラフAPI、およびファイルへの/からのシーンの保存/読み取りのための抽象化、およびGUI統合の両方を提供します。

OpenGLはOpenInventorよりもはるかに進んでいます（より差し迫ったニーズを満たし、ビデオハードウェアメーカーが最適化できるものを提供し、3Dアクセラレーションハードウェアを直接処理する代わりに一般的な低レベルAPIをターゲットにできるようにしました）。しかし、OpenInventorはまだ世に出ており、Unix / X11、Windows、およびMacOS X / Cocoaをサポートする優れたオープンソース実装（Coin3D）があります。

— 賢い
ソース

-2

これらのライブラリは、まったく新しいものではありません。それらはC APIであり、悪い点です。あなたの前提には欠陥があります。

— DeadMG
ソース

OpenGLはどのようにモダンではありませんか？

— ジェームズ

1

私は実際にこれに同意する必要があります。OpenGLは、管理している状態にアクセスして操作するためのモデルが1990年代初期のハードウェアに基づいているという点で、最新ではありません。テクスチャを特定のユニットの特定のターゲットにバインドし、VRAMにあるテクスチャの数に関係なく、限られた数のテクスチャのみを使用できるようにする必要はありません。

— user1118321