CおよびC ++プロジェクトのアセンブリの高速化

多くのプログラマーは、CおよびC ++のプログラムが非常に長い間続いていることを直接知っています。 誰かが集会中に剣と戦うことでこの問題を解決し、誰かがキッチンに行って「コーヒーを飲む」ことで解決します。 この記事は飽き飽きしている人のためのもので、彼は何かをする時だと判断しました。 この記事では、プロジェクトのアセンブリを加速するためのさまざまな方法と、「1つのヘッダーファイルを修正-プロジェクトの半分が再構築された」という病気の治療について分析します。

一般原則

始める前に、C / C ++コードを実行可能プログラムに変換する主な段階を見つけて思い出してみましょう。



N1548ドラフト「プログラミング言語-C」の5.1.1.2節およびN4659ドラフト「Working Draft、プログラミング言語C ++の標準」の節（標準の公開バージョンはこことここで購入できます）に従って、8段階と9段階の翻訳がそれぞれ定義されています。 詳細を省略して、翻訳プロセスを抽象的に見てみましょう。

• フェーズI-ソースファイルはプリプロセッサの入力に送られます。 プリプロセッサは、＃includeで指定されたファイルの内容の置換を行い、マクロを展開します。 ドラフトC11およびC ++ 17のフェーズ1から4に対応します。
• フェーズII-前処理されたファイルはコンパイラー入力に到着し、オブジェクトに変換されます。 ドラフトC11のフェーズ5〜7およびドラフトC ++ 17の5〜8に対応します。
• フェーズIII-リンカーはオブジェクトファイルと提供された静的ライブラリをリンクし、実行可能プログラムを形成します。 それぞれドラフトC11およびC ++ 17のフェーズ8および9に対応します。

プログラムは翻訳単位（* .c、* .cc、* .cpp、* .cxx）で構成されており、それぞれが自給自足であり、互いに独立して前処理/コンパイルできます。 このことから、各翻訳単位には他の単位に関する情報がないことにもなります。 2つの翻訳単位が何らかの情報（関数など）を交換する必要がある場合、名前でリンクすることでこれを解決します。外部エンティティはexternキーワードで宣言され、フェーズIIIではリンカーがそれらを接続します。 簡単な例。



TU1.cppファイル：

// TU1.cpp #include <cstdint> int64_t abs(int64_t num) { return num >= 0 ? num : -num; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TU2.cppファイル：

 // TU2.cpp #include <cstdint> extern int64_t abs(int64_t num); int main() { return abs(0); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さまざまな翻訳単位の調整を簡素化するために、ヘッダーファイルメカニズムが発明され、明確なインターフェイスの宣言で構成されました。 その後、必要に応じて、各翻訳単位に#includeプリプロセッサディレクティブを使用してヘッダーファイルが含まれます。



次に、さまざまな段階でアセンブリを高速化する方法を検討します。 原則自体に加えて、アセンブリシステムでこのメソッドまたはそのメソッドを実装する方法を説明することも役立ちます。 次のビルドシステムの例を示します： MSBuild 、 Make 、 CMake 。

コンパイルの依存関係

コンパイル時の依存関係は、C / C ++プロジェクトのビルド速度に最も影響を与えるものです。 #includeプリプロセッサディレクティブを使用してヘッダーファイルをインクルードするたびに発生します。 この場合、どのエンティティにもアナウンスのソースは1つしかないと思われます。 現実は理想とはほど遠い-コンパイラは異なる翻訳単位で同じ広告を繰り返し処理する必要があります。 マクロはさらに画像を台無しにします。ヘッダーをインクルードしたら、マクロ宣言を追加します。その内容は根本的に変わる可能性があるためです。



依存関係の数を減らすいくつかの方法を見てみましょう。



方法N1：未使用の包含物を削除​​します。 使用していないものに支払う必要はありません。 したがって、プリプロセッサとコンパイラの両方の作業を削減します。 ヘッダー/ソースファイルを手動で「シャベル」するか、次のユーティリティを使用できます： include-what-you-use 、 ReSharper C ++ 、 CppClean 、 Doxygen + Graphviz （包含図を視覚化するため）など。



方法N2：定義ではなく、宣言への依存関係を使用します。 2つの主な側面を区別します。



1）リンクまたはポインターを使用できるヘッダーファイルでオブジェクトを使用しないでください。 リンクとポインターの場合、コンパイラーはリンク/ポインターのサイズ（プラットフォームに応じて4または8バイト）を認識し、転送されるオブジェクトのサイズは重要ではないため、先頭の宣言で十分です。 簡単な例：

 // Foo.h #pragma once class Foo { .... }; // Bar.h #pragma once #include "Foo.h" class Bar { void foo(Foo obj); // <=    .... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、最初のヘッダーを変更すると、コンパイラーはFoo.hとBar.hの両方に依存する翻訳単位を再コンパイルする必要があります。



このような接続を解除するには、値によってobjオブジェクトを渡すことを拒否し、 Bar.hヘッダーのポインターまたはリンクで渡すことを優先します。

 // Bar.h #pragma once class Foo; // <=    Foo class Bar { void foo(const Foo &obj); // <=     .... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

標準ヘッダーについては、ここで心配する必要はなく、必要に応じてヘッダーファイルに含めるだけです。 唯一の例外はiostreamです。 このヘッダーファイルのサイズは非常に大きくなっているため、 iosfwdヘッダーも付属しています。これには、必要なエンティティの主要な宣言のみが含まれています。 それがヘッダーファイルに含まれるべきものです。



2） Pimplまたはインターフェイスクラスのイディオムを使用します。 Pimplは、ポインターを介してオブジェクトにアクセスできる別のクラスに実装の詳細を配置することにより、実装の詳細を削除します。 2番目のアプローチは、抽象基本クラスの作成に基づいており、その実装の詳細は、純粋な仮想関数をオーバーライドする派生クラスに転送されます。 どちらのオプションも、コンパイル段階で依存関係を排除しますが、プログラムの実行中のオーバーヘッドにも寄与します。つまり、動的オブジェクトの作成と削除、間接アドレス指定レベルの追加（ポインターによる）。 インターフェイスクラスの場合は別に-仮想関数を呼び出すコスト。



方法N3（オプション）：さらに、主要な広告のみを含むヘッダーを作成できます（ iosfwdに類似）。 これらの「主要な」ヘッダーは、他の通常のヘッダーに含めることができます。

並列コンパイル

標準的なアプローチでは、コンパイラは前処理とコンパイルのために何度も新しいファイルを受け取ります。 各翻訳単位は自給自足であるため、高速化する良い方法は、一度にN個のファイルを処理しながら、I-II翻訳のフェーズを並列化することです。



Visual Studioでは、プロジェクトレベルの/ MP [processMax]フラグによってモードが有効になります。processMaxは、コンパイルプロセスの最大数を制御するオプションの引数です。



makeモードでは、 -jNフラグがオンになります。Nはコンパイルプロセスの数です。



CMakeを使用する場合（およびクロスプラットフォーム開発でも）、- Gフラグを使用して、 ビルドシステムの広範なリスト用のファイルを生成できます。 たとえば、CMakeは、C ++アナライザーPVS-Studio用のWindows用Visual StudioおよびLinux用Unix Makefileのソリューションを生成します。 CMakeがVisual Studioソリューションで/ MPフラグを使用してプロジェクトを生成するには、 CMakeLists.txtに次の行を追加します。

 if (MSVC) target_compile_options(target_name /MP ...) endif()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、CMake（バージョン2.8.0以降）を介して、並列フラグを使用してアセンブリシステムを呼び出すことができます。 MSVC（/CMakeLists.txtで指定されたMP ）およびNinja（同時実行は既に有効になっています）の場合：

 cmake --build /path/to/build-dir
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メイクファイルの場合：

 cmake --build /path/to/build-dir -- -jN
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

分散コンパイル

前のヒントを使用すると、アセンブリ時間を大幅に短縮できます。 ただし、プロジェクトが巨大な場合、これでは十分ではない場合があります。 コンパイルプロセスの数を増やすと、プロセッサ/ RAM /ディスクの操作により、同時にコンパイルされるファイルの最大数という形で障壁に直面します。 ここでは、背後の同志の無料のリソースを使用して、分散コンパイルが助けになります。 アイデアは簡単です：



1）1つのローカルマシンまたは使用可能なすべてのマシンでソースファイルを前処理します。



2）前処理済みファイルをローカルマシンとリモートマシンでコンパイルします。



3）他のマシンからの結果をオブジェクトファイルの形式で期待します。



4）オブジェクトファイルを作成します。



5）????



6）利益！



分散コンパイルの主な機能を強調します。

• スケーラビリティ-私たちは車を引っ掛けて、今では組み立てに役立ちます。
• 分散コンパイルの有効性は、ネットワークと各マシンのパフォーマンスに依存します。 各マシンの同様のパフォーマンスを強くお勧めします。
• すべてのマシン（コンパイラー、ライブラリーなどのバージョン）に同一の環境が必要です。 これは、すべてのマシンで前処理が行われる場合に特に必要です。

最も有名な代表者は次のとおりです。

• IncrediBuild
• distcc
• アイスクリーム

Linuxでは、distccとIcecreamをいくつかの方法で簡単に統合できます。



1）シンボリックリンク（symlink）を介したユニバーサル

 mkdir -p /opt/distcc/bin #  /opt/icecc/bin ln -s /usr/bin/distcc /opt/distcc/bin/gcc ln -s /usr/bin/distcc /opt/distcc/bin/g++ export PATH=/opt/distcc/bin:$PATH
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2）CMakeの場合、バージョン3.4以降

 cmake -DCMAKE_CXX_COMPILER_LAUNCHER=/usr/bin/distcc /path/to/CMakeDir
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイラーキャッシュ

ビルド時間を短縮するもう1つの方法は、コンパイラキャッシュを使用することです。 コード変換のフェーズIIを少し変更しましょう。

現在、その内容、コンパイルフラグ、コンパイラ出力に基づいて前処理されたファイルをコンパイルするときに、ハッシュ値が計算されます（コンパイルフラグを考慮に入れます）。 その後、ハッシュ値とそれに対応するオブジェクトファイルがコンパイラキャッシュに登録されます。 変更されていないファイルの同じフラグを使用して再コンパイルすると、既製のオブジェクトファイルがキャッシュから取得され、リンカー入力に送られます。



使用できるもの：

• Unixライクの場合： ccache （GCC、Clang）、 cachecc1 （GCC）。
• Windowsの場合： clcache （MSVC）、 cclash （MSVC）。

ccacheを後で使用するために登録するには、いくつかの方法があります。



1）シンボリックリンクを介したユニバーサル

 mkdir -p /opt/ccache/bin ln -s /usr/bin/ccache /opt/ccache/bin/gcc ln -s /usr/bin/ccache /opt/ccache/bin/g++ export PATH=/opt/ccache/bin:$PATH
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2）CMakeの場合、バージョン3.4以降

 cmake -DCMAKE_CXX_COMPILER_LAUNCHER=/usr/bin/ccache /path/to/CMakeDir
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイラキャッシュは、分散コンパイルに統合することもできます。 たとえば、distcc / Icecreamでccacheを使用するには、次の手順を実行します。



1） CCACHE_PREFIX変数を設定します。

 export CCACHE_PREFIX=distcc #  icecc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2）ccache登録のポイント1-2のいずれかを使用します。

プリコンパイル済みヘッダーファイル

多数のソースファイルをコンパイルする場合、実際には、コンパイラは同じジョブを何度も実行して、重いヘッダー（ iostreamなど ）を解析します。 主なアイデアは、これらの重いヘッダーを個別のファイル（通常はプレフィックスヘッダーと呼ばれる）に配置することです。ファイルは一度コンパイルされ、 最初にすべての翻訳単位に含まれます。



MSVCでは、プリコンパイル済みヘッダーを作成するために、 stdafx.hおよびstdafx.cpp （他の名前を使用できます）の2つのファイルがデフォルトで生成されます。 最初のステップは、/ Yc 決定パス-stdafx.hフラグを使用してstdafx.cppをコンパイルすること です。 デフォルトでは、 .pchファイルが作成されます。 ソースファイルのコンパイル時にプリコンパイル済みヘッダーを使用するには、flag / Yudeterminedpath-to-stdafx.hを使用します。 / Ycおよび/ Yuフラグと共に、 / Fp "path-to-pch"を使用して、 .pchファイルへのパスを指定することもできます。 ここで、各翻訳単位のプレフィックスヘッダーを最初のヘッダーに接続する必要があります。 #include "path-to-stdafx.h"を直接使用するか、/ FIパラメーター path-to-stdafx.hフラグを強制的に使用します 。



GCC / Clangでのアプローチはほとんど異なりません。通常のコンパイル済みファイルではなく、プレフィックスヘッダーをコンパイラに直接渡す必要があります。 コンパイラは、デフォルトの.gch拡張子を持つプリコンパイル済みヘッダーを自動的に生成します。 -xスイッチを使用すると、さらにc-headerまたはc ++-headerとして扱うかどうかを指定できます。 #includeまたは-includeフラグを使用して、手動でプレフィックスヘッダーを含めます。



プリコンパイル済みヘッダーの詳細については、 こちらをご覧ください 。



CMakeを使用する場合は、 cotireモジュールを試すことをお勧めします。ソースファイルを自動的に分析し、プレフィックスとプリコンパイル済みヘッダーを生成して、翻訳ユニットに接続できます。 独自のプレフィックスヘッダー（たとえば、 stdafx.h ）を指定することもできます。

シングルコンパイルユニット

このメソッドの本質は、他の翻訳単位を含む単一のコンパイル済みファイル（翻訳単位）を作成することです：

 // SCU.cpp #include "translation_unit1.cpp" .... #include "translation_unitN.cpp"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての翻訳単位が単一のコンパイル済みファイルに含まれている場合、この方法はユニティビルドとも呼ばれます。 Single Compilation Unitの主な機能を以下に挙げます。

• コンパイルされたファイルの数が著しく減少するため、ディスク操作の数が減少します。 コンパイラは同じファイルをはるかに少なく処理し、テンプレートをインスタンス化します。 これはビルド時間に著しく影響します。
• コンパイラは、リンカで利用可能な最適化を実行できるようになりました（リンク時間の最適化/プログラム全体の最適化）。
• シングルコンパイルユニットの一部として単一のファイルを変更すると、その再コンパイルが発生するため、インクリメンタルアセンブリはわずかに劣化します。
• Unity Buildを使用すると、分散アセンブリを使用できなくなります。

アプローチを適用する際に起こりうる問題に注意します。

• ODR違反（マクロ名、ローカル静的関数、グローバル静的変数、匿名名前空間の変数の一致）。
• namespaceを使用して使用するための名前の衝突。

マルチコアシステムの最大の利点は、次のスキームを提供することです。

• プリコンパイル済みヘッダーを使用した複数のシングルコンパイルユニットの並列コンパイル。
• コンパイラキャッシュを使用した複数のシングルコンパイルユニットの分散コンパイル。

CMakeを使用する場合、 このモジュールでSCU生成を自動化できます。

ブロードキャストコンポーネントの交換

翻訳コンポーネントの1つをより高速なアナログに置き換えると、アセンブリ速度も向上します。 ただし、これは自分の責任で行ってください。



より高速なコンパイラとして、 Zapccを使用できます。 著者は、プロジェクトの再コンパイルの複数の加速を約束します。 これはBoost.Mathを再コンパイルする例で見ることができます：

Zapccはプログラムのパフォーマンスを犠牲にすることなく、Clangに基づいており、Clangと完全に互換性があります。 ここでは、Zapccがどのように機能するかを確認できます。 プロジェクトがCMakeに基づいている場合、コンパイラの交換は非常に簡単です。

 export CC=/path/to/zapcc export CXX=/path/to/zapcc++ cmake /path/to/CMakeDir
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または：

 cmake -DCMAKE_C_COMPILER=/path/to/zapcc \ -DCMAKE_CXX_COMPILER=/path/to/zapcc++ \ /path/to/CMakeDir
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OSがオブジェクトファイル（Unixのようなシステム）にELF形式を使用している場合、GNU ldリンカーをGNU goldに置き換えることができます。 GNUゴールドは、バージョン2.19からbinutilsにバンドルされており、 -fuse-ld = goldフラグでアクティブ化されます。 CMakeでは、たとえば次のコードを使用してアクティブ化できます。

 if (UNIX AND NOT APPLE) execute_process(COMMAND ${CMAKE_CXX_COMPILER} -fuse-ld=gold -Wl,--version ERROR_QUIET OUTPUT_VARIABLE ld_version) if ("${ld_version}" MATCHES "GNU gold") message(STATUS "Found Gold linker, use faster linker") set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fuse-ld=gold") set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fuse-ld=gold ") endif() endif()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SSD / RAMDiskを使用する

アセンブリの明らかなボトルネックは、ディスク操作の速度（特にランダムアクセス）です。 プロジェクトまたはその一時ファイルをより高速なメモリ（ランダムアクセス速度が向上したHDD、SSD、HDD / SSDからのRAID、RAMDisk）に転送すると、状況によっては非常に役立ちます。

C ++のモジュラーシステム

上記の方法のほとんどは、C / C ++言語の翻訳の原則の選択により歴史的に生じてきました。 ヘッダーファイルのメカニズムは、見かけの単純さにもかかわらず、C / C ++プログラマにとっては多くの問題です。



かなり長い間、C ++標準にモジュールを含めることについての議論がありました（そして、おそらくC ++ 20に登場するでしょう）。 モジュールは、モジュールインターフェイスと呼ばれる外部（エクスポートされた）名前の特定のセットを持つ翻訳ユニット（ モジュラーユニット ）の関連セットと見なされます 。 モジュールは、インターフェースを介してのみインポートするすべての翻訳ユニットで使用できます。 エクスポートされない名前は、モジュールの実装に配置されます 。



モジュールのもう1つの重要な利点は、ヘッダーファイルとは異なり、マクロやプリプロセッサディレクティブによって変更されないことです。 逆もまた真です。モジュール内のマクロとプリプロセッサディレクティブは、それをインポートする変換単位に影響しません。 意味的には、モジュールは独立した、完全にコンパイルされた翻訳単位です。



この記事では、将来のモジュールの設計については詳しく調べません。 それらについて詳しく知りたい場合は、 CppCon 2017でのC ++モジュールに関するBoris Kolpakovのプレゼンテーションをご覧になることをお勧めします（アセンブリ時間の違いも示されています）。







現在までに、 MSVC 、 GCC 、 Clangコンパイラは実験的なモジュールサポートを提供しています。

また、PVS-Studioアセンブリについて何かありますか？

このセクションでは、説明したアプローチがどれほど効果的で有用かを見てみましょう。



CおよびC ++コードを分析するためのPVS-Studioアナライザーのコアを取り上げましょう。 もちろん、C ++で書かれており、コンソールアプリケーションです。 コアは、LLVM / Clang、GCC、Chromiumなどの巨人に比べて小さなプロジェクトです。 たとえば、コードベースでCLOCが生成するものは次のとおりです。

 ---------------------------------------------------------------- Language files blank comment code ---------------------------------------------------------------- C++ 380 28556 17574 150222 C/C++ Header 221 9049 9847 46360 Assembly 1 13 22 298 ---------------------------------------------------------------- SUM: 602 37618 27443 196880 ----------------------------------------------------------------
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

作業を行う前に、作業マシンの次の構成でプロジェクトが1.5分で（並列コンパイルと1つのプリコンパイル済みヘッダーを使用して）組み立てられたことに注意してください。

• Intel Core i7-4770プロセッサー3.4 GHz（8 CPU）。
• RAM 16 Gb RAM DDR3-1333 MHz
• システムドライブとしてのSamsung SSD 840 EVO 250 Gb。
• WDC WD20EZRX-00D8PB0 2 Tbは作業ニーズに対応。

HDDでのプロジェクトのアセンブリを開始インジケータとして採用し、アセンブリ時間の最適化をすべて無効にします。 次に、測定の第1段階を示します。

• HDDでのアセンブリ、1ストリームでのコンパイル、最適化なし;
• SSDでのアセンブリ、1ストリームへのコンパイル、最適化なし;
• RAMDiskでのアセンブリ、1ストリームへのコンパイル、最適化なし。

図1. PVS-Studioアナライザーアセンブリ、1ストリーム、最適化なし。 上はデバッグバージョンアセンブリ、下はリリースです。



図からわかるように、ランダムアクセス速度が大きいため、1スレッドで最適化されていないRAMDiskのプロジェクトは高速になります。



測定の第2段階-ソースコードをファイルで変更します：ヘッダーの不要なインクルードの削除、定義への依存関係の排除、プリコンパイル済みヘッダーの改善（頻繁に変更されるヘッダーの削除）-最適化を徐々に強化します：

• 1ストリームでのコンパイル、HDD、SSD、RAMディスク上のプロジェクト：
  • シングルコンパイルユニット（SCU）;
  • プリコンパイル済みヘッダー（PCH）;
  • 単一のコンパイル単位+プリコンパイル済みヘッダー（SCU + PCH）。
  
  
  

図2.最適化後の1つのストリームへのコンパイル。

• 4つのストリームでのコンパイル、HDD、SSD、RAMDiskでのプロジェクト：
  • 単一のコンパイル単位。
  • プリコンパイル済みヘッダー。
  • 単一のコンパイル単位+プリコンパイル済みヘッダー

図3.最適化後の4つのストリームでのコンパイル。

• 8ストリームでのコンパイル、HDD、SSD、RAMDiskでのプロジェクト：
  • 単一のコンパイル単位。
  • プリコンパイル済みヘッダー。
  • 単一のコンパイル単位+プリコンパイル済みヘッダー
  
  
  

図4.最適化後の8スレッドでのコンパイル。



簡単な結論を下しましょう。

• SSD / RAMDiskを使用する利点は、モデル、ランダムアクセス速度、起動条件、ムーンフェイズなどによって異なります。 これらはHDDの高速なアナログですが、 特に私たちのケースでは、大きな利点はありません。
• プリコンパイル済みヘッダーは非常に効果的なツールです。 このメソッドは以前アナライザで使用されていましたが、1つのストリームにコンパイルする場合でも7〜8倍の加速が得られました。
• 少数の単一の翻訳単位（SCU）では、プリコンパイル済みヘッダーを作成しないことをお勧めします。 単一の変換ブロックの数が十分に大きい（> 10）場合は、プリコンパイル済みヘッダーを使用します。

おわりに

多くのプログラマーにとって、C / C ++言語は「ロングコンパイル」として関連付けられています。 そして、これには理由があります：一度に選択されたブロードキャスト方式、メタプログラミング（C ++の場合）、何千もの。記述された最適化方法のおかげで、過度に長いコンパイルに関するそのような偏見を自分自身から奪うことができます。特に、CおよびC ++コードを分析するためのPVS-Studioアナライザーコアのアセンブリ時間は、シングルコンパイルユニットとヘッダーおよびソースファイルの処理を統合することにより、1分30秒から40秒に短縮されました。さらに、最適化の開始前に並列コンパイルとプリコンパイル済みヘッダーが使用されていなかった場合、アセンブリ時間が7分の1に短縮されました。



結論として、この問題は標準化委員会でよく記憶されており、この問題の解決策は順調に進んでいると付け加えます。新しいC ++ 20標準を待っています。 C ++プログラマははるかに簡単です。