4

ある日、昔ながらの C 言語でビデオ ゲームを書き始めることにしました。
それはとても楽しく、3 か月後 (仕事から少し離れていることもあります)、物理エンジンが必要であることに気付きました。
Bullet 物理エンジンを使用することにしました。これは、私が必要としているものの中で最も優れているものの 1 つと思われるためです。
その後、Bullet には実際には C API がなく、完全な C++ API しかないことがわかりました。その C API は維持されていません。
のろいの一日の後、私は自分のプロジェクトを C++ に「変換」しました。これは、すべてのヒープ割り当てを型キャストし、malloc と free の代わりに new と delete を使用し、「extern "C" でいくつかの定義をまとめた」という大胆な声明です。 { ... }'.
そうすれば私を撃つ人もいるでしょうが、この物理エンジンのような C++ API しか持たないパフォーマンス タスクを C で使用する方法は他にありませんでした。

だから今、私はg ++でコンパイルしていますが、まだほとんど「C」コードを書いています。コードが純粋ではなくなったので、少し満足できなくなりました。
C++ を使用すると奇妙なエラー メッセージが表示されますが、g++ パーサーが嫌いな言語については特に何も感じていません。オブジェクト同士をうまく跳ね返すことができるようになったという事実は別として、私のペット プロジェクトの小ささと純粋さの一部は今では見捨てられています。

私は正しいことをしたかどうか疑問に思っています。「ほとんどの」C コードに C++ コンパイラを使用することを心配せずに続行する必要がありますか? パフォーマンスの低下や過度の保守作業を行わずに、C でこの API を使用する他の方法はありますか?

4

7 に答える 7

5

私は正しいことをしたかどうか疑問に思っています。

プロジェクトのコンポーネントが必要だったので、最初から再発明する代わりに、既存のソフトウェアを再利用しました。それは実際に私には正しいように聞こえます。

「ほとんどの」C コードに C++ コンパイラを使用することを心配せずに続行する必要がありますか?

まったく心配する必要はありません。C++ はほぼ 100% C と互換性があります。それを行うことに対する罰則はありません。より厳密な型システムにより、コンパイル時のチェックが実際に改善されました。

パフォーマンスの低下や過度の保守作業を行わずに、C でこの API を使用する他の方法はありますか?

いいえ、コードを C++ に変換せずに C で API を使用することはできません。C++ 識別子はマングルされています。これは、単純な C から C++ API を使用する準備ができていたとしても、それらを参照する方法がわからないことを意味します。理論的には可能ですが、実際には不可能です。

あなたのやり方が正しいです。そのゲームで頑張ってください！

于 2011-02-16T14:19:05.863 に答える
4

あなたは本当に問題ではないことについて自分自身を過度に心配していると思います。あなたは、純粋さのいくらかがなくなったと言います。まあ、これは理解できます。あなたはそれをCで書いた後、選択したAPIを使用するためにC ++を使用する必要があることに気づき、それをシューホーンしました。今では、ペットの赤ちゃんのようには感じられなくなりました。これは潜在意識の問題であり、プログラミングの問題ではありません。

弾丸をかじって（笑）、プロジェクトをC++で書き直すことをお勧めします。そうすれば、それは再び純粋になり、途中で多くのことを学び、C-childがソドム化されているように感じることはありません。

于 2011-02-16T14:16:13.207 に答える
3

エンジンのさまざまなサブシステムがどの程度緊密に結合されているかによっては、エンジンのさまざまな部分をさまざまな言語で記述できる可能性があります。

たとえば、物理部分を C API をエクスポートする C++ モジュールに分解して、アプリケーションの残りの部分を C のままにすることができます。ただし、システムの中心部分を C++ で記述して、既存の C コードを個別のモジュールに。

于 2011-02-16T14:45:01.193 に答える
2

プロジェクトを C で書きたい場合は、C で書き、ライブラリの C ラッパーを作成します。それについてのアドバイスについては、この質問を見てください。

それ以外の場合は、プロジェクトを C++ で書き直してください。ただし、あちこちで C++ を使用して別の C プロジェクトを作成しないでください。私の経験では、これらのプロジェクトはすぐに混乱する可能性があります (また、C の考え方でコードを記述し、C++ コードを呼び出すと、例外が発生したときに奇妙なことが起こり始めます)。ミックスに追加されます）。

于 2011-02-16T14:12:43.060 に答える
1

主に C コードを作成し、それを C++ でコンパイルすることについて心配する必要はありません。malloc/free の代わりに new/delete を使用するだけで問題ありません。new を使用する利点は、結果を適切なポインター型にキャストする必要がなく (C++ では void* から他のポインターへの暗黙のキャストは許可されていません)、new が無効なポインターを返さないことです。ただし、 realloc() を失います。（そして、いいえ、新規/削除をreallocと混合することさえ考えないでください:)）

于 2011-02-16T14:11:31.717 に答える
1

プロジェクトを「純粋な C」のままにしておく唯一の理由は、ソース コードの互換性、ツールのサポート、または言語標準 (MISRA-C など) のためです。「純粋に感じてほしい」というのは、あまり合理的な議論ではないでしょう。

このような理由でコードを純粋な C のままにしておくことが重要である場合は、C++ で「ラッパー」DLL (Windows を想定) を記述し、サードパーティ API とのすべての通信を行うことができます。もちろん、かなりのオーバーヘッドが発生します。

奇妙なエラー メッセージが表示されるのは、C++ でのより厳密なタイピングが原因であることは間違いありません。C++ コンパイラは、危険な暗黙の型キャスト (整数の昇格など) に遭遇すると、指を叩く可能性が高くなり、より厳密な「定数の正確性」を強制する可能性があります。しかし同時に、C では優れたジェネリック プログラミングと見なされているが、C++ では危険で、ずさんで、おそらく冗長であると見なされている void ポインターについて不満を言うでしょう。

于 2011-02-16T15:36:38.210 に答える
0

1 つのオプションは、LLVM を使用して C++ コードを C に変換することです。プロジェクトの Web サイトからこの FAQ を参照してください: C++ コードを C コードに変換できますか?

于 2011-02-16T14:12:29.157 に答える