C ++コードをクロスプラットフォームにする方法は？

おそらく、タイトルを読んだ誰かが尋ねるでしょう：「あなたのコードで何かをするのはなぜ？！ C ++はクロスプラットフォーム言語です！” 一般に、これはそうです...しかし、これまでのところ、コンパイラとターゲットプラットフォームの特定の機能との関係はありません...



実際には、特定のプラットフォームの特定のタスクを解決する開発者は、「C ++標準に正確に対応していますか？ コンパイラの拡張機能である場合はどうなりますか。」 彼らはコードを書き、ビルドを開始し、コンパイラが誓った場所を修復します。



その結果、特定のコンパイラー（およびその特定のバージョン！）およびターゲットOSにある程度対応するアプリケーションが得られます。 さらに、C ++標準ライブラリが不足しているため、特定のシステムAPIを使用せずに記述できないものもあります。



Tensorで私たちと一緒にいました。 MS Visual Studio 2010で作成しました。当社の製品は32ビットWindowsアプリケーションでした。 そしてもちろん、コードはマイクロソフトのテクノロジーとのあらゆる種類の結びつきに満ちていました。 新しい視野を探るときだと判断したら、VLSIにLinuxや他のOSで動作するように教えるときであり、別のハードウェア（POWER）に切り替えることを試みるときでした。



この一連の記事では、製品を実際のクロスプラットフォームアプリケーションにした方法を説明します。 Linux、MacOS、さらにはiOSやAndroidでどのように機能させたか。 さまざまなハードウェアアーキテクチャ（x86-64、POWER、ARMなど）でアプリケーションを起動した方法。 ビッグエンディアンのマシンでの作業を学ぶ方法。





すべての製品の基礎は、規模がQtに匹敵する独自のVLSIプラットフォームフレームワーク（以下「プラットフォーム」と呼びます）です。 プラットフォームには、開発者が必要とするほぼすべてのものがあります。数値を文字列形式にすばやく変換するための単純な関数から、強力なフォールトトレラントアプリケーションサーバーまで。



プラットフォームに基づいて、当社の開発者は、あらゆる種類のビジネス上の問題を解決する製品（モバイルアプリケーションも含む）を実装します。 コードを解放し（以下、コードを「適用済み」と呼びます）、ターゲットソフトウェアおよびハードウェアプラットフォームとのあらゆる種類の結び付きから解放し、フレームワークの奥深くにあるすべての仕様を隠しました。



VLSIプラットフォームはC ++で記述されていますが、これはアプリケーションプログラマーが言語を選択するのを制限するものではなく、C ++ JavaScript、Python、およびSQLを使用できます。



当社は積極的に製品を開発しているので、「フルスピードで電車を修理する」必要がありました:)





他の開発者が私たちの活動に悩まされず、MSVCでWindows機能を快適に開発し続けることができるように作業する必要がありました。 この要件は多くの技術的ソリューションに大きな影響を与え、作業を非常に複雑にしました。



読者が作品の規模を理解するために、いくつかの数字を挙げます。

• 私たちのフレームワークのコード量は〜200万行です
• 「適用された」コード（特定のビジネス上の問題を解決するVLSIプラットフォームに基づくコード）の量を評価することは困難ですが、プラットフォームの量の数倍です
• 10の開発センターにいる1000人以上のプログラマー

退屈なエントリーは終わりました。 それでは問題に近づき、どのような問題に遭遇したかを考えてみましょう。

オペレーティングシステムAPIの使用

前述のように、C ++標準ライブラリは非常に貧弱であり、必要な機能の多くが至る所に含まれていません。 たとえば、C ++ 11では、ネットワークを操作するための機能はありません...つまり、最も単純なHTTPリクエストを作成するとすぐに、強制的に...非プラットフォームコードを記述しなければなりません。



最新バージョンのコンパイラを使用していない場合、状況はさらに悪化します。MSVS2010では、C ++ 11の嫌なサポートがあり、コア言語と標準ライブラリの革新の大部分があります。



しかし、幸いなことに、このような問題は非常に簡単に解決できます。 いくつかの方法があります。

• ターゲットシステムのAPI呼び出しに基づくプラットフォーム固有の実装をいくつか使用して、独自のクラスを作成しています。 アセンブリ中に、ifdefプリプロセッサディレクティブは適切な実装を選択します。
• 私たちはクロスプラットフォームライブラリを使用しています-私たちのタスクを大幅に簡素化する多くの既製のクロスプラットフォームライブラリがあります（ここでも、プラットフォーム固有の実装を使用しています）。 たとえば、HTTPクライアントを実装するために、cURLを使用しました。

コンパイラー実装の機能

各プログラムにはエラーがあります。 そして、コンパイラも例外ではありません。 したがって、100％標準に準拠したコードでさえ、ある種のコンパイラでコンパイルされない場合があります。



また、ほとんどすべてのコンパイラ開発者は、標準では提供されていない機能を自分の頭脳に追加することを義務と考えており、それによってプログラマに耐えられないコードを書くよう促しています。



最後に何が得られますか？ 標準に従って明確に記述されたコードは、一部のコンパイラではコンパイルできない場合があります。 あるコンパイラでコンパイルおよび実行されるコードは、コンパイルされないか、別のコンパイラで正しく動作しない可能性があります...



このクラスの多くの問題をリストできます。 それらの1つを次に示します。

throw std::exception( "-   " ); //    MSVC++,       
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、追加のコンストラクターが定義されているため、MSVC ++でコンパイルされます。

 exception( const char* msg ) noexcept;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、そのような問題を解決する一般的なトリックはありません。 これらの場合、作業で使用されるツールの学習で得た経験と、C ++標準ヘルプの十分な知識のみが得られます。



後続の記事では、この問題に戻り、最も一般的な問題を詳細に説明し、それらを解決する方法を提案します。

未定義の動作

C ++標準には、「未定義の動作」という興味深い用語があります。 ウィキペディアからの彼の定義は次のとおりです。

未定義の動作（英語の未定義の動作、多くのソースでの予測不可能な動作[1] [2]）は、一部のプログラミング言語（Cで最も顕著）、ソフトウェアライブラリ、およびコンパイラの実装（ライブラリ）チップ）およびメモリステータスやトリガーされた割り込みなどのランダムな要因。 言い換えると、仕様では、可能な状況での言語（ライブラリ、マイクロサーキット）の動作は決定されませんが、「条件Aでは、操作Bの結果は定義されていません」と述べています。 プログラムでこのような状況を許可することは間違いと見なされます。 プログラムが一部のコンパイラで正常に実行されても、クロスプラットフォームではなく、別のマシン、異なるOS、または異なるコンパイラ設定で失敗する可能性があります。

プログラムで未定義の動作を許可する場合、これはクラッシュしたり、コンソールにエラーを投げたりすることを意味するものではありません。 このようなプログラムは期待どおりに機能する可能性があります。 ただし、コンパイラの設定を変更したり、別のコンパイラや別のバージョンに切り替えたり、コードを変更すると、プログラムの動作が変わり、すべてが破損する可能性があります。



特定のコンパイラで未定義の動作が発生する多くの状況では、同じ動作が安定して生成され、慎重にテストされたアプリケーションはスイス時計のように機能します。 しかし、環境を変更するとすぐに（たとえば、別のコンパイラーによってコンパイルされたプログラムを実行しようとすると）、これらのバグは宣言を開始し、プログラムを完全に破壊します。



未定義の動作の典型的な例は、スタック上の配列の境界を超えることです。 以下は、この問題を抱えるアプリケーションの1つの簡略化されたコードスニペットです。 このバグは、Windowsで数年間は現れず、Linuxへの移植後にのみ「発砲」しました。

 std::string SomeFunction() { char hex[9]; // some code hex[9] = 0; //      return hex; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どうやら、MSVSはスタック上のバ​​ッファーを調整し、その後に数バイトを追加していたため、誰かのメモリを上書きすると、空の未使用の場所になってしまいました。 そして、GCCでは、問題は興味深い方法で現れ始めました-プログラムは別の関数でこのコードから遠く離れました（明らかに、GCCはこの関数をインライン化し、別の関数のローカル変数を書き換え始めました）。



UBには、よりエレガントでわかりにくい状況があります。 たとえば、std :: sort：を使用すると、非常に興味深いレーキを実行できます。

 std::vector< std::string > v = some_func(); std::sort( v.begin(), v.end(), []( const std::string& s1, const std::string& s2 ) { if( s1.empty() ) return true; return s1 < s2; } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どこにUBがあるのでしょうか？ そして、問題は「悪い」コンパレータにあります。

s1をs2の前に配置する必要がある場合、コンパレータはtrueを返す必要があります。 2つの空の行が入力された場合にコンパレーターが生成するものを検討します。



s1 = "";

s2 = "";

cmp（s1、s2）== true => s1はs2の前になければなりません

cmp（s2、s1）== true => s2はs1の前になければなりません



したがって、コンパレータがそれ自体に矛盾する場合、つまり厳密な弱い順序付けを指定しない場合があります（ en.wikipedia.org/wiki/Weak_ordering#Strict_weak_orderingsへのリンク）。 したがって、引数のstd :: sortの要件に違反し、未定義の動作が発生しました。



そして、これは発明された例ではありません。 Linuxに切り替えたときにこの問題を発見しました。 同様のエラーのコンパレータは、Windowsで長年機能し、... Linux（i686）でSIGSEGVを使用してアプリケーションをクラッシュさせ始めました。 興味深いことに、バグは異なるLinuxディストリビューション（異なるGCCを搭載）でも異なる動作をします。アプリケーションがクラッシュしたり、フリーズしたり、単純にソートされたりします。



多くの場合、未定義の動作を伴う状況は、静的アナライザー（コンパイラーに組み込まれているものを含む）によってキャッチできます。 したがって、ビルド設定では、常に警告の最大レベルを設定する必要があります。 また、「未使用の変数」タイプの警告の群集で有用な警告を失わないようにするには、コードを一度クリーンアップし、「警告をエラーとして扱う」アセンブリオプションを有効にして、気付かない新しい警告が表示されないようにします。

データモデル

C ++標準は、コンピューターのメモリ内のデータ型の表現に関する厳密な保証を提供していません。 いくつかの関係のみを定義し（たとえば、sizeof（char）<= sizeof（short）<= sizeof（int）<= sizeof（long）<= sizeof（long long））、型の特性を決定する方法を提供します。



異なるシステムでは、型の表現方法は大きく異なる場合があります。 基本型の次元は、データモデルによって定義されます。 データモデルは、開発環境内で採用されている型のディメンションの比率として理解される必要があります。 以下の表は、一般的なデータモデルと、主要なC ++型の対応する次元を示しています。





ほとんどの場合、プログラマは、データ型を選択するときに、そのサイズについて保証する必要があります。 しかし、実際には、開発者は多くの場合、作業するシステム内の基本型のサイズに単純に縛られています。 繰り返しますが、別のソフトウェアまたはハードウェアプラットフォームに切り替えると、驚きが生じます。一部のコードはコンパイルを停止し、一部は異なる動作を開始するか、完全に動作を停止します。



たとえば、次のハッシュ関数は、異なるプラットフォームで起動すると、同じデータに対して異なる結果を生成します。

 unsigned long some_hash( const unsigned char* buf, size_t size ) { unsigned long res = 0; for( size_t i = 0; i < size; ++i ) res = res * buf[i] + buf[i] + i; return res; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの問題のほとんどは、サイズが保証された型を使用して解決できます。

 std::int8_t, std::int16_t  . . std::uint32_t some_hash( const unsigned char* buf, size_t size ) { std::uint32_t res = 0; for( size_t i = 0; i < size; ++i ) res = res * buf[i] + buf[i] + i; return res; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チャーサイン

charがサインなのか疑問に思っている開発者はあまりいないと思います。 そして、そのような質問が生じた場合、ほとんどの人はお気に入りの開発環境を開き、小さなテストプログラムを作成して答えを得るでしょう...システムにのみ当てはまります。



実際、C ++標準では、charのchar文字は指定されていません。 このため、charが署名されているコンパイラの実装と、charが署名されていないものがあります。 また、これは、別のシステムのアセンブリ後にプログラムが動作を拒否する別の理由です。



たとえば、このコードはLinux x86-64では正常に動作しますが、Linux POWERでは動作しません（GCCでデフォルトパラメータを使用してビルドする場合）。

 bool is_ascii( char s ) { return s >= 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

不確実性を取り除くには、目的の型に明示的なキャストを追加するだけです。

 bool is_ascii( char s ) { return static_cast<signed char>( s ) >= 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、ビット操作のコードを完全に書き換えることができます。

 bool is_ascii( char s ) { return s & 0x80 == 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

文字列ビュー

C ++標準は、特定の側面を何らかの方法で規制するものではなく、各コンパイラーはその裁量でこれらの問題を解決します。



たとえば、文字列定数がメモリ内でどのように表現されるかについての保証はありません。

MSVSコンパイラはWindows-1251で文字列定数をエンコードしますが、GCCはデフォルトでUTF-8で文字列定数をエンコードします。



このような違いがあるため、同じコードでは異なる結果が得られます。MSVSで構築されたプログラムのstrlen（ "Habr"）は4を返します。 GCCで-8。



同じ問題は、データの入力と出力でも発生します。 たとえば、テストプログラムでは、いくつかのテキストファイルにデータを保存して読み取ることができます。

 std::string readstr() { std::ifstream f( "file.txt" ); std::string s; std::getline( f, s ); return s; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 void writestr( const std::string& s ) { std::ofstream f( "file.txt" ); f.write( s.c_str(), s.size() ); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのファイルが1つの環境で収集されたアプリケーションによって書き込まれ、読み取られる限り、すべてが正常に機能します。 しかし、このファイルがWindowsアプリケーションに書き込まれ、Linuxの下でアプリケーションを読み取るとどうなりますか？..「krakozyabry」を取得します:)









そのような場合はどうすればいいですか？ 考えられる解決策の一般原則は1つだけです。プログラムメモリで文字列を表す統一された方法を選択し、I / O時に文字列の明示的なエンコード/デコードを行うことです。 多くの開発者は、プログラムでUTF-8エンコーディングを使用しています。 これは非常に良い解決策です。



しかし、前述したように、「列車を全速力で修理」し、コードが依存していた不変条件の一部を破ることができませんでした（文字列エンコードがWindows-1251であることを考慮して開発されました）。

• 固定文字幅-インデックスによる文字へのランダムアクセスが可能
• コードでロシア語の文字列定数を書くことが可能です

UTF-8エンコーディングでは、文字は異なるバイト数で表すことができるため、最初の要件を満たしていません。 UTF-8の場合の2番目の要件は、たとえば、文字列定数がWindows-1251でエンコードされているMSVC 2010では満たされていません。 そのため、UTF-8を放棄する必要があり、...行が表示されているエンコーディングから完全に切り離し、「ワイド文字列」に切り替えることにしました。



このソリューションは、要件をほぼ完全に満たしました。

• ほとんどすべてのUNIXシステムでは、「ワイドライン」はUTF-32エンコーディングで表されます。つまり、その中の文字の幅は固定され、タイプwchar_tの要素のサイズと一致します。
• WindowsはUTF-16を使用します。 一部の文字はサロゲートペアで表すことができるため、このエンコーディングでは状況がやや複雑になります。 しかし、幸いなことに、Windowsアプリケーションが機能するWindows-1251にあるすべてのものは、2バイトシーケンスで表されます。 したがって、初期段階では、サロゲートペアをまったくサポートせず、Windowsではすべての文字がwchar_t型の1つの要素に収まると仮定しました。
• C ++では、「L」「Hello、Habr！」などの「ワイド」文字列定数を指定できます。 この場合、コンパイラはこの行をソースファイルのエンコーディングからwchar_tがターゲットシステムで表されるエンコーディングに変換する処理を行います。

さらに、「幅の広い線」を使用すると、多くの利点が得られました。

• 標準CおよびC ++ライブラリには、「ワイド文字列」を操作するための多くの関数とクラスがあります。strlen、strstr関数、std :: string、std :: stringstreamクラスなどに独自の類似物を書く必要はありません。
• 多くのサードパーティライブラリがワイド文字列をサポートしています（たとえば、BOOST）
• ほとんどのWinAPIは「ワイドライン」で動作します

必要なすべてのプラットフォームで、「ワイド文字」はUnicodeで表されます。 このため、アプリケーションはラテンアルファベットとキリルアルファベットに限定されなくなり、世界中のあらゆる言語をサポートします。



実際、エンコーディングの戦いは、製品を移植する上で最も困難な部分でした。 彼女についてもっと詳しく知ることができます-次の記事のためにこれを残しましょう:)

OSファイルシステムの機能

Windowsファイルシステムには、ほとんどのFS UNIXライクシステムといくつかの違いがあります。

1. 彼女は大文字と小文字を区別しません
2. 文字「\」をパス区切り文字として使用できます

これは何につながりますか？ ヘッダーファイルに「FiLe.H」という名前を付け、コードに「#include <myfolder \ file.h>」と記述します。 Windowsでは、このコードはコンパイルされますが、Linuxでは、「myfolder \ file.h」という名前のファイルが見つからないというエラーが表示されます。



しかし、幸いなことに、このような問題を回避するのは非常に簡単です-ファイルの命名規則（たとえば、すべてのファイルに小文字を付ける）を受け入れ、それらに固執し、常にパス区切り文字として「/」を使用します（Windowsもサポートしています）



迷惑なエラーを完全に排除するために、gitリポジトリに単純なフックを追加し、includeディレクティブがこれらのルールに準拠しているかどうかを確認します。



また、FSの機能はアプリケーション自体に影響します。 例えば

 std::string root_path = get_some_path(); std::string path = root_path + '\\' + fname;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常の文字列連結操作でパスを「固定」し、区切り文字として「\」を使用するコードがある場合、一部のオペレーティングシステムでは区切り文字がファイル名の一部として解釈されるため、壊れます。



もちろん、「/」を使用できますが、Windowsでは見た目が悪く、一般に、他のセパレーターが使用されるOSがないという保証はありません。



この問題を解決するには、boost ::ファイルシステムライブラリを使用します。 現在のシステムのパスを正しく形成できます。

 boost::filesystem::path root_path = get_some_path(); boost::filesystem::path path = root_path / fname;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

C ++でのクロスプラットフォームソフトウェアの開発は簡単な作業ではありません。 さまざまなソフトウェアおよびハードウェアプラットフォームで動作するプログラムを作成するために、追加の努力をせずに作成することはおそらく不可能です。 また、C ++はクロスプラットフォーム言語であるにもかかわらず、OSおよびハードウェアのコンパイラで変更せずに正しくアセンブルできるC ++の大規模プログラムを開発することは不可能です。 ただし、この記事で簡単に説明したいくつかのルールを順守している場合は、必要なすべてのプラットフォームで実行されるコードを作成できます。 はい。このプログラムを新しいOSまたはハードウェアに移行することは、それほど難しくありません。



合計、必要なクロスプラットフォームコードを作成するには：

• C ++標準を理解し、その中で許可されているものを理解し、特定のコンパイラの拡張とは何か、さらには未定義の動作につながることを理解することは有益です。
  
  
  
  
• 一部のクラスでプラットフォーム固有のコードをカプセル化することにより、コードでシステムAPIを使用することを拒否するか、既製のクロスプラットフォームライブラリを使用します。
  
  
  
  
• 入力の違いの可能性を考慮し、C ++標準で保証されていない基本型のプロパティに依存しないでください。 このために、標準C ++ライブラリの固定次元の型を使用できます。
  
  
  
  
• プログラムメモリ内の文字列を表す形式を決定します。 多くのオプションがあります。 たとえば、多くのプログラムで行われているようにUTF-8を使用するか、「ワイド」行に完全に切り替えて、表示行の形式からまったく抽象化します。
  
  
  
  
• 異なるオペレーティングシステム上のファイルシステムの機能を考慮してください（コード、＃includeディレクティブ、およびプログラム自体のロジックの両方）。

著者：アレクセイ・コノバロフ