C ++ 0x。 含まれていない



新しい標準C ++ 0xに関する記事は既にHabréで実行されています-その中に含まれるものとその使用方法。 そして、この記事はそこに入ることができたものに関するものですが、特定の理由で拒否されました。



コンセプト



コンセプトは、テンプレートの使用を拡張する非常にクールなものです。 要するに、この概念により、テンプレートで使用されるタイプの要件を提示することができます。 たとえば、パブリックコンストラクタとデストラクタの存在、特定のインターフェイスのサポートなどを要求できます。 コンセプトが非常に役立つ可能性があるという考えがあります-エラーの数を減らし、テンプレートタイプを操作するときの愚かなコンパイラメッセージを避け、テンプレートタイプのユーザーに、このタイプがその引数で行うことについて理解を与えます。 一般的に、クール。 類似したものは、たとえば、C#にあります。

2009年7月にC ++ 0xドラフトからコンセプトが削除され、「準備ができていません」という文言が追加されました。 これにはいくつかの理由がありました。

  1. 提案されたフォームでは、あまりにもだまされました。 概念を説明する補足には、1.5ページが必要でした(標準の残りの部分は約800であるという事実にもかかわらず)。 少し複雑でした。 彼らはそれを単純化しようとした-しかしそれはさらに悪いことが判明した。 人々の半分は、必要なものをカットしたと不満を言い始めました。2番目は、残りはまだ複雑すぎたということです。
  2. 個人的なイニシアチブの一環として、プログラマのいくつかの個別グループが、コンパイラに概念を実装しようとしました。 もちろん、GCCで。 たとえば、 これとさらにいくつかのオプションが判明しました。 それらはすべて、コンパイルと結果のプログラムの作業の両方で非常に平凡なパフォーマンスを示しました。 また、概念を使用した例だけでなく、通常のテンプレートも使用します。 実装は「理論的な可能性の証明」として認識されましたが、実際の使用には適していません。
2年以上にわたり、さまざまな人々がこのすべての跳躍で何かをしようとしました。 しかし、新しいC ++標準を開発しようとしている群衆全体にとって2年はほんの一瞬です。 何も解決できませんでした。 新しい標準には概念はありません。 誰もが楽観的ですが、彼らは微笑んで手を振る。 詳細はこちらをご覧ください



ガベージコレクター



C ++での自動ガベージコレクション-ここにあります、holivarの肥沃なフィールドです! あなたの槍、マウスとキーボードの高貴な騎士を研ぎます、ここであなたは彼らの間でそして異なるトロルの群衆の両方で素晴らしい戦いを見つけるでしょう! まあ、それは神聖なもののガベージコレクションのために何ですか-C ++?! 一方、他の言語でこの禁断の果実を知っている人は誰でも、見下ろして、甘いと言います。 3番目-下位互換性、タイプセーフティ、または常識を損なうことなく、C ++で#$%を実装する方法 4番目の-他の言語では、この問題を何らかの形で解決しましたか? 第5に、他の言語は主婦とインド人向けであり、C ++はタオを知っている人向けです。 一般的に、この主題についての25回目の考えの後のどこかで、私は道を迷い始め、始まりを忘れます。 同じ平面のどこかにC ++標準化委員会があります。 C ++ 0xでは、ガベージコレクターはありません。



モジュール



必要に応じて、作業の出力で再利用可能なコンポーネント(ライブラリ)を作成すると、* .hファイルと、実際にはコンパイルされたライブラリ(オープンソースの場合はソース)が得られることをご存知でしょう。 同時に、他の言語(同じC#)では、出力に1つのアーティファクトのみがあります。ライブラリ自体は、メタデータにそのすべてのタイプと機能の自己記述を含みます。 C ++のモジュールアーキテクトの主なアイデアは、同じことを達成することです。 自分で判断してください:複数のファイルが存在しないため、混乱が少なくなり、非同期エラーが少なくなり、コード実装の詳細が少なくなり、一般的に非常に便利です。 しかし、* .hファイルがない場合、これはどのように使用できますか? さて、このようなもの:

import std; // Module import directive. int main() { std::cout << “Hello World\n”; }
      
      





ソースをヘッダーファイルと実装ファイルに分割する何世紀も昔の伝統を取り除くという考えは、想像力を刺激します。 世界はそのようなショックにまだ準備ができていません。 C ++ 0xでは、この機能を期待しないでください。

ベンチャーを説明する優れたドキュメント: www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2316.pdf



GUI、数学特殊機能、ネットワーキング、ファイルシステム



「Hello world」ステージを通過した多くの初心者プログラマーは、実際のタスクに直面しており、基本構成(コンパイラー+標準ライブラリー)のC ++などの強力でクールな言語ではほとんど何もできないことに驚いています。 ウィンドウを取得したり、ネットワーク経由で2バイトを送信したり、XMLを解析したりする必要はありません。 必要なのは、個々のライブラリを検索するか、オペレーティングシステムAPIを使用するか、未記述コードの未使用の土地を手動で耕すことです。 それから、「そして、標準としての言語が歌って踊ることができるようにする」という精神に変人がいます。 標準化委員会の意見は破れません。 ハエ-別に、カツレツ-別に。 段落の見出しに示されているものの一部は、単に船外に放り出されているものもあれば、次のTRで検討される予定のものもあります。 C ++ 0xではそうではありません。



スレッドプール、タスクの起動、リーダーライターロック



並列プログラミングの重要性を一般的に理解している(そして、C ++ 0xでは多くのすべてがそれだけのために追加されたことを認めなければなりません)、考えられるすべてのアイデアを実装する方法はありません。 つまり 本当にしたいのですが、標準のリリースをさらに5年間延期する必要があります。しかし、リリース日はすでに設定されており、赤いリボンが引っ張られ、ビュッフェテーブルのウォッカが加熱され、ローストが冷却されます。 そのため、コナ市での会議では、「コナの妥協」が採択されました。これは、とりわけ、次のTRまたは標準でそれらを検討することを約束して、スレッドのプールといくつかの他のクールなものを標準から捨てました。



マクロスコープ



Stroustrupのページのよくある質問で、 マクロに対する彼の批判を読むことができます 。 一般的に、それは現代の若者についての入り口での祖母の考えに似ています:マクロは、境界を知らず、可視性、クラス、名前空間、その他すべての領域を気にしません。 この無礼とフレームワークの移行は、しばしばマクロと古き良きコードの衝突に満ちており、時にはマクロ自体も互いに衝突します。 これらの新興企業にサンドボックスでの位置を説明し、その範囲の概要を説明するとよいでしょう。 それはちょうどそのように見えるはずです

正直なところ、このアイデアが標準に含まれていない理由に関する情報は見つかりませんでした。 これらの同じ地域と古き良き#defineと#undefディレクティブの相互作用の詳細を理解している人は誰もいないように思えます。 どういうわけかそれはすべて直感的ではありません。 一般に、これまでのところ、このことはC ++ 0xにはありません。



リフレクション



それが何であるかを知っている人は、この場所に驚いています。 知らない人のために、私は説明します-これはすべてのmerc兵目的のためにデータ型とその内部に関する情報を取得して操作する方法です。 クラスに特定のシグネチャを持つメソッドがあるかどうかを確認したり、メソッドコードをその場で変更したり、クラスのプライベートメソッドを外部から呼び出したり、他の操作を実行したりできます。 このことは、さまざまなロガー、moka、プラグインなどの開発に非常に役立ちます。 また、C ++にリフレクションがない理由は客観的ではありません。必要な情報はすべてコード内にあり、コンパイラがそれを保持しており、実行時に取得できます。 少なくともStraustrup これに対する障害を見ません 。 しかし、どうやら、他の誰かが見ています。 したがって、C ++ 0xには反映されません。



結論



大聖堂とバザール
残念ながら、他の多くの集団プロジェクトとは異なり、C ++標準に関する集団作業は、利点よりもむしろ不利益につながることに注意してください。 C#や他の言語(大企業とクリエーターによってサポートされている)ですべてが個別に決定され、新しいアイデアの生成からその実装まで1年が経過した場合、C ++では10年前から合意できない考えがいくつかあります12。 バザールはバザールであり、大聖堂は大聖堂です。 それにもかかわらず、人生はまだ止まっておらず、論文はフォルダからフォルダへと転送され、電子メールのキャリアは電子メールとを運び、記事「live」に記載されているすべてのものを見る機会があります。



デジャヴ




この記事を書く過程で、私はdeja vuの感覚を残しませんでした。 どこかですでに見たことがあります! しかし、どこに? そうそう-C ++ / CLIで! 実際、C ++によって管理されているMicrosoftの奇妙な子孫は、新しい言語としてではなく、古いC ++コードと.NETプラットフォームの「橋」として作成され、この記事で説明されている概念とガベージコレクターのほとんどすべてを備えています。 、モジュール、および.NETおよびReflectionクラスライブラリのフルパワー。 一度も役に立たない-純粋なC ++ / CLIで新しいプロジェクトを開始する人はいません(C#とVBの方がはるかに便利です)。言語はMicrosoftが計画した場所に完全に取って代わりました-古いコードを使用する必要があるプロジェクトC ++および.NETで。 これは、Microsoftだけが、10年半にわたって国境を越えた同盟が選んでいたことをなんとかしてさえいなかったのは楽しいことです。 次に何が起こるか怖いです。 3つのオプションがあります。

  1. コミュニティは、説明されているすべてのことの標準として、Microsoftの実装を採用しています。 これは屈辱的であり、したがってありそうもない。
  2. 会話はさらに10年間続きます。 より活発な同僚の猛攻撃の下で、舌はゆっくりと吹き飛ばされます。
  3. Allianceは、コンセプト、ガベージコレクタなどの独自の実装を受け入れます。 異なる構文で。 これは最も黙示録的なオプションです。言語の異なる方言では同じことが別の方法で実装されるためです。 そしてこれはカペットです。
一般的に、待って、それがどうなるかを見てください。 C ++で記述してください。



All Articles