エンコーダーが特定の機能を実装するにはGoogleで十分ですが、特別な設計要件はありますか？ プロジェクト内のプラットフォーム固有の部分を強調表示する唯一の方法は、メソッド内の #ifdef 分岐だとしましょう か？ （パスタはたくさんありませんか？） #ifdef よりも上位のアプローチ、テンプレート、「アドオン」はあり ますか？ この投稿がさらなる議論の糧になることを願っています。
クロスプラットフォーム開発の経験から、いくつかの簡単な原則を学びました。これらの原則に従うと、一般的なトラップを回避できます。
- MVCの概念でアプリケーションを開発します。 おそらく、これがクロスプラットフォームプロジェクトの成功の主な鍵です。
- 最初から、WindowsとMacの2つのコマンドが動作するはずです。 クロスプラットフォームに真剣に取り組んでいるのであれば、設計と実装の初期段階で両方のグループの経験がすでに必要です。 1
- VCSでコードの1つのブランチを使用します。 個々のブランチはしばしば制御不能になり、同期されなくなります。 2 #ifdefを使用して、特定のプラットフォーム用にコーディングします。
- ANSI標準に準拠したC / C ++コードを記述します。 標準のANSIおよびSTLライブラリを使用します。 多くのクロスプラットフォームプロジェクトは複数のコンパイラを使用するため、コンパイラのエラーと警告を最小限に抑えることが重要です。 高い警告レベルを含めることをルールにし、すべてのコードに警告がないことを確認します。
- MacとPCを各開発者のテーブルに置きます。 定期的に、あるプラットフォームの開発者が自分のコードが別のプラットフォームにどのように影響するかを知りたいときに状況が発生します。 開発者が別のマシンに簡単にアクセスできない場合、コミットによって別のプラットフォームのアプリケーションが破損する可能性が高くなります。
注釈
[1]この重要な点は、1999年に私が働いていたチームでは見逃されていました。 このプロジェクトはMVC上でうまく構築されました。 モデルはC ++ DLL、プレゼンテーションはJNI経由のSwing、すべてはMac OSおよびWindows用のCodeWarriorで記述されています。 これまでのところいいですね。 そのため、Windowsチームは最初にプロジェクトを作成し、それをMacintoshチームに渡しました。 その後、アプリケーションはJava 2仕様で記述されていたことが判明しましたが、この仕様はMacではサポートされませんでした。 さらに-さらに：ソースファイル名がFinderの制限である31文字を超えており、プロジェクトファイルは＃includが壊れているためコンパイルできませんでした...経営者はプロジェクトを2つのブランチに分割することにしました。 Mac開発者にチームに最初からアドバイスしてもらうと、これらの損失を回避できます。 ^
[2]私はかつて1つのプロジェクトを率いていましたが、経営陣はコードをフォークして、Macバージョンを以前に起動することにしました。 この決定により数か月は節約されましたが、2つのブランチを再びマージするのにさらに1年半かかりました。 ^
結論（翻訳者から）
ヒントは当たり前のことですが、このことから、このような経験のない人にとっても価値があります。 脚注は特に注目に値します。 プロジェクトを分岐することを恐れるべき最初のことのようです、なぜなら分離のための百万の動機があるかもしれず
MacおよびLinuxでMFCアプリケーションを書き換え、GUIはHTML5 / WebKitで書き換えられます。 これは私たちにとって初めてのプロジェクトです。最大数のレーキを避けたいと思います...あなたの経験を共有してください！ 私の側では、結果によると、Habrの購読を解除します。