C ++ StandardとBoostの比較

Boostでより良いものを作成するために、C ++コミュニティは標準に準拠する必要がありますか？





待って、間違ったライブラリ。



2011年3月、ISO C ++委員会は、最新のC ++標準の最終ドラフトを承認しました。 その言語は、その年の8月に正式に標準化され、C ++ 11として知られるようになりました。2年後、言語に影響する問題のいくつかを振り返って見ることができます（1998年に最初の国際標準が採用されて以来）その最終バージョンを一般的なC ++ Boostライブラリと比較します。





標準の最初のバージョンでは、C ++にライブラリの公式仕様が含まれていました。 これに先立ち、さまざまな組織や個人がライブラリを作成しました。テンプレートをベースにして、ベクターやスタックなどのさまざまな種類のコンテナを提供することもありました。 ANSI / ISOの注目に値するそのようなライブラリの1つは、Alexander Stepanovという名前の男が立ち上げたStandard Template Library（STL）です。 しかし、当時は言語自体に標準はなく、コンパイラのさまざまなサプライヤが喜ん​​でそれを解釈する機会がありました。 （90年代半ばにBorland C ++コンパイラを使用して「リンクをリセット」することが可能でしたが、標準のリリースでは不可能になりました）。



テンプレートは、別の問題でした。 ベンダーはさまざまな方法でそれらを実装しました。 ただし、STLの出現により、C ++の重要なギャップ、特に、明確に定義され、十分にテストされたコンテナクラスの必要性が埋められました。 しかし、人生が蜜に見えないように、さまざまなSTL実装がすぐに登場しました。 HPのバージョン（元のバージョンの1つ）をどのように使用したかを覚えており、同時に会社もSilicon Graphicsのバージョンを選択しました。 同時に、Rogue Wave Softwareのすばらしいライブラリが存在しました。このライブラリには、テンプレートに基づいたものとそうでないものがありました。 これは当時最も人気のあった商用ライブラリの1つであり、STLをsomewhatとさせます。 重要な点：これらのライブラリはいずれも交換可能ではありませんでした。 同じクラスと関数が使用されていると想定されている場合でも、それを取得して「#include」を別のライブラリに置き換え、すべてが機能することを期待することはできません。 それらは単に互換性がありませんでした。 2つのライブラリが元のSTLに基づいて「ベクター」クラスを実装したという事実は、同じであることを意味しませんでした。

カオス

その後1998年に、標準ライブラリと呼ばれる独自のライブラリ仕様を含む標準が発表されました。 それはSTLによく似ており、実際にそれに基づいていました。 これは言語仕様の一部でしたが、コンパイラに組み込まれていないという意味で標準ライブラリは一部ではありませんでした。 このライブラリは、ベンダーがC ++で開発し、コンパイラに同梱できる一連のクラスの仕様でした。 これは、必要に応じて標準ライブラリを無視し、代わりに別のライブラリを使用できることを意味します。これは、電気通信業界向けのソフトウェアを作成した若いエンジニアなど、ほとんどの組織が行ったことです。 この会社では、私より前に働いていたプログラマーがSTLバージョンのSilicon Graphicsを使用していましたが、これから離れて標準ライブラリの実装に置き換えるには多大な労力が必要でした。 もちろん、1999年にコンパイラの最新バージョンに切り替えて多くの変更を加えた後、ベンダーは、コンパイラが標準に準拠していることを誇らしげに発表しました。つまり、私たちが書いたコードのほとんどは、常に新しいコンパイラによってコンパイルされたわけではありません。



そのため、ソフトウェア開発者は新しいプロジェクトを開始するタイミングを選択せざるを得ませんでした。標準ライブラリまたは実績のあるSTLを使用し、STLの場合はどのバージョンですか または、Rogue Waveのような優れた商用ライブラリーに立ち寄ってください。 彼らはまた、それらのいずれかを選択すると、長期間使用することを余儀なくされることを理解しました。 標準ライブラリ自体については、コンパイラベンダーが独自のバージョンを作成することが多く、常にオリジナルと一致するとは限りませんでした。



それは完全な混乱でした。 そして、部分的には、標準化プロセス自体が問題でした（現在は問題です）。 STLは1993年に標準化委員会で初めて実証されましたが、標準が発表されるまでに5年が経過しました。 その間、ライブラリは言うまでもなく、言語自体の標準さえなかったため、コンパイラベンダーはライブラリを作成する自由だけでなく、言語自体も受け取りました。 1996年頃、混乱は最高潮に達しました。 Borlandは、C ++のバージョンに多くの新機能を組み込みましたが、別のコンパイラでコードを単純にコンパイルすることは不可能でした。 また、STLを使用する場合は、コンパイラに移植されたバージョンを見つける必要がありました。



1998年までに、ほとんどのベンダーは標準に従ってコンパイラを更新しましたが、これはあまり役に立ちませんでした。 以前のバージョン用に大量のコードが作成されました。 実際、一部の企業は、古いコードのコンパイルが停止するため、新しいコンパイラにアップグレードできませんでした。 コンピューターの世界では多くのことが6年にわたって行われ、コンパイラベンダーは、今後の標準にもかかわらず、新しいバージョンをリリースし続けました。



このプロセスではほとんど変更はありません。 2006年（小さな更新の3年後）に、新しいC ++標準が現実になるはずです。 最終的に2011年に登場しました。 多くの時間が経ちました。

ブースト

2000年代初頭、新しいライブラリの人気が高まっていました-Boost。



Boostは、標準ライブラリだけでなく言語自体のさまざまなギャップを埋めるC ++ライブラリのセットです。 C ++は、開発の4年後の1983年に登場し、1972年に登場したCに基づいていました。



正直に言うと、私はC ++が本当に好きで、それでも（特に私のフリーランスプロジェクトの1つであるマルチコアプログラミングに）使用しているという事実にもかかわらず、実際には、 JavaやPythonのように、言語に直接組み込まれた便利な機能（C ++の一部ではない機能）を見つけることができます。 地獄、文字列型はまだ言語のコアに組み込まれていませんが、標準ライブラリのテンプレートとして実装されています。 言語自体は、依然としてシンボリックポインターとリンクに基づいています。 文字列が必要な場合は、ライブラリの1つを使用し、文字列クラスのc_str（）メソッドを呼び出して、文字へのポインターを取得する必要があります。 文字列は 、リストや辞書などは言うまでもなく、言語にネイティブに埋め込まれていないためです。 Pythonのリストが必要ですか？ 「a = [1,2,3]」と入力するだけです。 できた



ラムダ関数（多くの言語でもネイティブにサポートされています）など、より高度なものについては、これがBoostのようなライブラリが役立つ場所です。



もちろん、C ++の基本的な違いは、完全にコンパイルされていることです。 しかし、これは、C ++がJITコンパイルを使用する場合と使用しない場合の両方で、現代の動的言語よりも優れていて高速であるかどうかを吐き気にさせる議論です。



Boostライブラリは最終的にいくつかの目的を果たします。まず、プログラマーに関数型プログラミングなどの高度な機能と、スマートポインターなどの基本的な機能の両方を提供します。 第二に、それは標準になり得る新しい言語機能のための一種のインキュベーターです。



Boostのメインページで 、その構成から10個のライブラリがC ++ 11標準に含まれていることに気付きました。はい、標準の採用のずっと前の10年前の2003年にリリースされました。



なぜなら 2011標準の採用には非常に時間がかかり、多くの開発者がBoost（または完全に放棄されたC ++）の使用を開始しました。 それでは、BoostとStandardを比較しましょう。

2011 StandardおよびBoost

C ++ 11標準には、言語自体にいくつかの変更が含まれています（たとえば、「外部テンプレート」の使用を可能にするテンプレートコンパイルメカニズムが整いましたが、コンテナーオブジェクトの初期化はどれだけ簡単か、さらにはタイプ決定メカニズムもメカニズム））。 しかし、標準には標準ライブラリの多くの改善も含まれています。



前述の重要な注意事項があります。標準には標準ライブラリの説明が含まれていますが、コンパイラまたは言語の実装は含まれていません。 これらはすべて、コンパイラプロバイダーなどのサードパーティの良心に任されています。 リファレンス実装はありません。 標準はコードではなく、 説明です。



また、Boostについて知っておく必要があることの1つは、実際には複数のライブラリで構成されており、デザイナーがそれらを意図的に分割していることです。 つまり、必要なBoostのライブラリのみを使用できます。 そこにはいくつかの相互依存関係がありますが、十分に文書化されています。 このようにして、必要に応じてBoostを標準ライブラリと組み合わせることができます。 たとえば、古き良きiostreamは1998年の最初の標準以来標準ライブラリの一部であり、Boostはそれらと簡単に連携します（ただし、必要に応じて独自のiostreamも含まれます）。



ただし、実際には、Boostは標準ライブラリよりもはるかに優れています。 約175のクラスが含まれており、 SourceForge（1.53.0）の現在のバージョンには93 MBが必要です（ドキュメントを含む、展開された.hppファイルは9000個で90 MBが必要です）。 たとえば、「言語機能エミュレーション」のカテゴリに属する​​クラスなど、仕事で個人的に非常に役立つと思うクラスがあります。 たとえば、foreachコンストラクトは、C ++のテンプレートエンジンのおかげで、次のように標準のC ++ループを超えるループを作成できます。

int i = 0; BOOST_FOREACH( i, container ) { … }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネイティブループを使用してコードを簡単に記述できますが、この方法でコードを記述したい理由はいくつかあります。 まず、コーディングが少し簡単になっています。 2つ目は、ジュニア（または昇進すべきではないと思うシニアでも）が、「 for（i = 0; i <= length; i ++） 」などのように書くことで、同じ古い間違いをする可能性が低いことです。 、そして、彼らはまだこのコードが時々動作する理由を尋ねます、そして時々それはそれが呼び出された関数内に落ちます。



Boostは、強力ではあるが高度に専門化されたクラスの膨大な品揃えも提供します。 たとえば、数年前、グラフを操作するためのライブラリが必要でした。 Boostには1つあります。 多次元配列が必要ですか？ スタックベースのコンテナはどうですか？ Boostはそれをすべて備えています。 しかし、私が最も気に入っているのは、一連の優れたプログラミングパターンと、正規表現を操作するための便利なライブラリです。



しかし、Boostの実装はそれほど単純ではなく、開発者はライブラリにコンパイラ依存コードを追加する必要がありました。 たとえば、foreachコンストラクトの実装には次のコードが含まれます。

 # if BOOST_WORKAROUND(BOOST_MSVC, <= 1300) || BOOST_WORKAROUND(__BORLANDC__, < 0×593) || (BOOST_WORKAROUND(BOOST_INTEL_CXX_VERSION, <= 700) && defined(_MSC_VER)) || BOOST_WORKAROUND(__SUNPRO_CC, < 0×5100) || BOOST_WORKAROUND(__DECCXX_VER, <= 60590042) # define BOOST_FOREACH_NO_RVALUE_DETECTION # endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、ライブラリを使用するすべての人に適しています-ほとんどの一般的なコンパイラで動作し、その微妙さから完全に抽象化されます。

しかし、今は別の規格があります

そのため、Boostは成長を続けましたが、この標準に関する作業は2011年に先立って行われました。 独自の正規表現クラスなど、Boostの対応するクラスと多くの共通点がある、いくつかの素晴らしいクラスが含まれています。



しかし、標準はどうですか？ ベンダーの観点から見てみましょう。 C ++標準が完成するまでには何年もかかりました。 1998年の標準は、テンプレートやリンクなど、言語の多くの基本的な側面を確立したため、重要でした。 これにより、ライブラリ作成者の生活がずっと楽になりました。 ただし、Boostのコンパイラ依存マクロによって証明されるように、コンパイラはまだ異なります。 一部には、これは文字通り標準に準拠していないベンダーのせいですが、ライブラリ自体のランダムな不確実性も原因です。



2011年の標準に先行する数年間に、いくつかの変更も加えられました。 コンパイラベンダーは、標準が終了する前に既に標準化された製品を使用することを望んで、コンパイラと標準ライブラリの実装を提供しようとしました。 しかし、彼らは動く標的を撃ちました。



GNU GCCとMicrosoftのC ++の2つの特定のコンパイラを見てみましょう。 この表によると 、GCC 4.8の現在のバージョンは、2つの小さな機能（「* this」および「最小ガベージコレクションサポート」の右辺値リンク）を除く、ほぼすべての新機能をサポートしています。 しかし、開発者は、このサポートがまだ実験段階にあることを明らかにしました。



Microsoftの次の表は、Visual Studio 2012のステータスを示しています。多くの「いいえ」と「部分的」があります。 ただし、Microsoftページのこの小さなメモに注意してください。



" - ( 0.9) (mutable lambdas), 1.0, . 1.1. , Visual C++ 2010, Visual Studio 2012."







ここでの注意は、言語自体にあります。 しかし、標準ライブラリはどうでしょうか？ マイクロソフトは、非常に初期の段階で標準に準拠するための取り組みに関与してきました。 しかし、彼らは、このライブラリの一部がまだ実装されていない言語の新機能に依存していることを説明しました。 その結果、ライブラリのこれらの側面も実装されませんでした。 （しかし、彼らはどれを示しませんでした）。



そして、これが標準ライブラリのGNU実装です 。 「N」および「Partial」というラベルの要素が多数あります。

比較

標準が形になり始める前に10年が経過し、承認に2年かかりました。 この間に多くの変更が行われたため、コンパイラの製造元は、後で元に戻すことができる機能を実装することでリスクを負うことはできません。 あまりいい写真ではありません。



ブーストは、同時に良好な進歩を遂げました。 開発者は、コードがさまざまなコンパイラで動作することを確認して、すばらしい仕事をしました。 Boostは熟しており、十分にテストされており、正常に機能します。 開発プロセスは、標準化委員会の障害なしに前進しています。 彼女は進化し続けます。



標準ライブラリの変更についてはどうですか？ 正規表現ライブラリについては既に説明しましたが、これは非常によく似ており、Boostの影響を強く受けています。 しかし、標準ライブラリにはまだ仕様の多くの実装が欠けているという事実を考えると、それは重要ですか？ C ++標準はコードではなく、参照実装もありません。 標準は、C ++コンパイラが何をすべきか、標準ライブラリの実装に何をすべきかを単に示しています。 標準ライブラリを使用する場合は、GCCやMicrosoftバージョンなど、多くの場合コンパイラにバンドルされているサードパーティ製品を使用する必要があります。 そして、実際に選択するものは次のとおりです。GCC、または標準ライブラリのモデル化に基づいたMicrosoftの標準ライブラリまたはBoostの実装。 そして、これらの実装は両方とも完全ではなく、そのうちの1つは「実験的」と呼ばれます。 あなたの製品でどちらを使いたいですか？



標準化委員会が標準に何を含めるべきかを理解するのに8年かかりました。コンパイラ製造業者は、標準ライブラリのバージョンを公開する前にすべてが解決するまで待たなければなりません。 代わりに、彼らはせいぜいアルファ版である作品を公開しました。 そして、彼らはまだ終わっていません。 同時に、実際のC ++コミュニティは前進しており、Boostなどのより良いものを作成しています。



数年後には、新しい標準が登場します。 私たちはすでにこれを経験しています。 ブーストはそれまでにさらに良くなります。