少し低レベルの C++ を書くと、OS 固有のものを書かなければならないことがよくあります。例として関数を見てみましょうMessageBox()(フレームワークがこれを行うため、素晴らしい例ではありませんが、従うのは簡単です)。
各プロジェクトが のようなカスタム サブクラスを提供する基本AppクラスがあるとしますMyApp。OSごとに複数のブロックを持つ単一のApp::MessageBox()メソッドを持つことができます。#ifdefまたは、OS ごとのサブクラスが実装を提供する基本クラス/インターフェイスを持つこともできます。例えばAppWin32 : public App
ある意味では後者の方がきれいに思えますMyAppが、別の意味では、正しい OS 固有の基本クラスをサブクラス化するために、醜いコードを使用する必要があることを意味します。
より良いアプローチは何ですか？
file/socket/memory/database/... 関数は GUI 関数よりもプラットフォームごとの違いが少ないため、ほとんどのコードはすべてのアーキテクチャで共有/コンパイルされます。これらの関数/クラス内のプラットフォーム固有のコードの周りに #ifdef ブロックを使用するだけです。
完全に異なる GUI (またはその他の複雑なサブシステム) コードについては、プラットフォーム ディレクトリの下にある別の実装 (ヘッダーではなく、おそらく内部ヘッダー) ファイルを使用する必要があります。(windows/window.cpp、xwin/window.cpp、macosx/window.cpp、...)
このスキームの GUI ツールキット、wxwidgets や fltk、その他のほとんどを見てみましょう...
IMO、オープン/クローズなど、一部のクラスは単純すぎますが、これらの状況では #ifdef は悪くありません。単純な関数に抽象的なプラットフォーム レイヤーを提供することは良い考えではないと思います。過剰なエンジニアリングです。
しかし、クロスプラットフォームは複雑です。ターゲット プラットフォームに存在しない特定のプラットフォーム機能を提供する場合は、抽象プラットフォーム レイヤーを作成し、プラットフォームごとに実装する必要があります。たとえば、Windows のクリップボードは X11 の X 選択と大きく異なるため、維持する必要があります。それらを統一するための異なるデータ構造とアルゴリズム。
実装を複数の .cpp ファイルに移動する場合、使用できる #ifdef ブロックは 1 つだけです。ただし、必要に応じて、これを2番目のアプローチと組み合わせることもできます。それでも、簡単に使用するには、複数の定義ファイルでうまくいくと思います。
#ifdef は間違いなく最悪です。
プラットフォーム固有のコードを別のソース ツリー (プラットフォームごとに 1 つのツリー) に配置します。プロジェクトの場所 (特定のプラットフォームの場合) から、2 つのファイルシステム リンクを使用できます。「ユニバーサル」ツリー (たとえば、「src」という名前) とプラットフォーム固有のツリー (たとえば、「特定」という名前で、実際には Linux、Windows を指しています) へのリンクです。 、または他のプラットフォーム固有のソース ルート)。これにより、クラスの適切なバージョンを常に選択することが保証されます。さらに、異なるプラットフォーム用に設計された同様のクラスに同じ名前を付けることもできます。
もちろん、このアプローチは FAT ファイルシステムを使用する Windows では不可能ですが、現在では非常にまれなケースです (通常、Windows で NTFS を使用しない理由はないため)。