C でクロスプラットフォーム アプリケーションを作成する際に最も留意すべきことは何ですか? 対象プラットフォーム: 32 ビット Intel ベースの PC、Mac、および Linux。特に、Jungle Disk の USB デスクトップ エディション ( http://www.jungledisk.com/desktop/download.aspx )にある多用途性を探しています。
このタイプの開発のヒントと「落とし穴」は何ですか?
C でクロスプラットフォーム アプリケーションを作成する際に最も留意すべきことは何ですか? 対象プラットフォーム: 32 ビット Intel ベースの PC、Mac、および Linux。特に、Jungle Disk の USB デスクトップ エディション ( http://www.jungledisk.com/desktop/download.aspx )にある多用途性を探しています。
このタイプの開発のヒントと「落とし穴」は何ですか?
私は何年もの間、30 近くの異なる OS とコンパイラに移植された ANSI C ネットワーク ライブラリを維持してきました。ライブラリには GUI コンポーネントがないため、作業が簡単になりました。最終的に、プラットフォーム間で一貫性のないルーチンを専用のソース ファイルに抽象化し、それらのソース ファイルで適切な場所に #defines を使用しました。これにより、プラットフォームごとに調整されたコードが、ライブラリの主要なビジネス ロジックから分離されたままになりました。また、必要に応じてプラットフォームごとに簡単に変更できるように、typedef と独自の専用型を多用しました。これにより、64 ビット プラットフォームへの移植がかなり容易になりました。
GUI コンポーネントが必要な場合は、WxWindows や Qt (どちらも C++ ライブラリ) などの GUI ツールキットを検討することをお勧めします。
新しいプラットフォームを追加すると指数関数的に大きくなる傾向があるため、プラットフォームに依存する #ifdef は避けるようにしてください。代わりに、プラットフォームに依存しないコードをルートに、プラットフォームに依存するコードを「葉」に持つツリーとしてソース ファイルを整理してみてください。これについては、 Multi-Platform Code Managementという優れた本があります。その中のサンプル コードは時代遅れに見えるかもしれませんが、この本で説明されているアイデアは今でも非常に重要です。
Kyle の回答に加えて、Windows で Posix サブシステムを使用しないことを強くお勧めします。これは、Microsoft がフィーチャー シートのチェック ボックスで「Posix サポート」を主張できるように、最低限のレベルで実装されています。誰かが実際に使っているのかもしれませんが、私は実際に遭遇したことはありません。
クロスプラットフォームの C コードを書くことは確かにできますが、プラットフォーム間の違い、およびテスト、テスト、テストに注意する必要があります。単体テストと CI (継続的インテグレーション) ソリューションは、プログラムがすべてのターゲット プラットフォームで動作することを確認するのに大いに役立ちます。
良いアプローチは、システムに依存するものをせいぜい 1 つまたはいくつかのモジュールに分離することです。そのモジュールからシステムに依存しないインターフェイスを提供します。次に、そのモジュールの上に他のすべてをビルドして、コンパイルするシステムに依存しないようにします。
XVT にはクロスプラットフォーム GUI C API があり、これは 15 年以上成熟しており、ネイティブ ウィンドウ ツールキットの上にあります。WWW.XVT.COM を参照してください。
少なくとも LINUX、Windows、および MAC をサポートします。
できるだけ POSIX で書くようにしてください。Mac と Linux は POSIX をネイティブにサポートしており、Windows にはそれを実行できるシステムがあります (私の知る限り、実際に使用したことはありません)。アプリがグラフィカルな場合、Mac と Linux の両方が X11 ライブラリ (Linux はネイティブ、Mac は X11.app を介して) をサポートし、X11 アプリを Windows で実行するにはさまざまな方法があります。
ただし、真のマルチプラットフォーム展開を探している場合は、Java や Python など、ほとんどまたはまったく変更せずに複数のシステムで同じプログラムを実行できる言語に切り替える必要があります。
編集:アプリケーションをダウンロードしてファイルを見ました。3 つのプラットフォームすべてのバイナリが 1 つのディレクトリにあるようです。設定を失わずにマシンからマシンに移動できるアプリを作成する方法に関心がある場合は、すべての構成を実行可能ファイルと同じディレクトリ内のファイルに書き込み、Windows レジストリに触れたり、ドット ディレクトリを作成したりしないでください。 Linux または Mac でプログラムを実行しているユーザーのホーム フォルダー。また、クロスディストリビューション Linux バイナリを作成する限り、32 ビット POSIX/X11 がおそらく最も安全な方法です。現在Macを使用しているため、JungleDiskが何を使用しているのかわかりません。
また、ifdef ではなく、異なるプラットフォームのコードを異なるモジュール/ツリーに分割するという推奨事項にも賛成です。
また、プラットフォームの違いと、それらをどのように抽象化できるかを事前に確認することをお勧めします。たとえば、これは OS 関連のもの (たとえば、テキスト ファイルの迷惑な CR、CRLF、LF)、またはハードウェアのものです。たとえば、前述のposix互換性はあなたを止めません
int c;
fread(&c, sizeof(int), 1, file);
しかし、異なるハードウェア プラットフォームでは、内部メモリ レイアウトが完全に異なる (エンディアン) 場合があり、一部のターゲット プラットフォームでは変換関数を使用する必要があります。
私が過去に取り組んだ例にすぎない移植可能なライブラリはほとんどありません
1) glib と gtk+
2) リブカール
3) ライブラリ
これらはほぼすべてのプラットフォームをカバーしているため、非常に便利なツールです。
Posix は Unice では問題ありませんが、移植可能な GUI 用のものがないことを除けば、Windows ではそれほど優れているとは思えません。