2

最初は、次のC ++ 0x標準を見たとき、私は喜んでいました。悲観的ではありませんでしたが、今それを考えると、少し希望が薄れています。

主に3つの理由があります。

  1. 多くのブースト肥大化（これは絶望的なコンパイル時間を引き起こす必要がありますか？）、
  2. 構文は長いようです（私が最初に望んでいたほどPythonicではありません）。
  3. 私は携帯性と他のプラットフォーム（iPhone、Xbox、Wii、Mac）に非常に興味がありますが、「標準」が十分に携帯可能になるまでに時間がかかるという非常に現実的なリスクはありませんか？

＃3はリスクが少ないと思います。これは、過去10年間にテンプレートから学んだ教訓です。しかし、悪魔は細部に宿っています。

編集2（気まぐれを少なくしよう）：企業が規格の最初の発効年にC ++ 0xに移行するのは安全だと思いますか、それとも大きなリスクに関連しますか？

4

8 に答える 8

14
  1. 使用した分だけお支払いいただきます。複雑なテンプレート機能が必要ない場合は、それが定義されているヘッダーを #include しないでください。対処する必要はありません。
  2. Lambda 関数は、STL アルゴリズムの冗長性をかなり軽減する必要があります。auto変数は次のようなコードに役立ちますstd::map<foo, std::shared_ptr<std::vector<bar> > >::const_iterator...
  3. はい、しばらく時間がかかります。新機能の多くは確かに後押しされており、移植性が必要な場合は、標準が実装されてから少なくとも数年間使用する必要があります. 幸いなことに、あなたが言及したこれらのプラットフォームをカバーするコンパイラは、g++ と Microsoft の C++ コンパイラの 2 つだけです。サポートが得られれば、組み込みツールチェーンが新しいバージョンで再構築されるのは時間の問題です。残念ながら、おそらく多くの時間...
于 2009-08-12T15:24:52.867 に答える
13

編集：私（および私のような他の人）は、ビルド時間、読み取り不可能なコード、および移植性の欠如に非常に注意を払い、新しい標準を安全に進めるために大規模なプロトタイピングを行う必要がありますか？

はい。しかし、これらすべてのことを現在の標準でも行う必要があります。C++0xで悪化しているとは思いません。

C++のビルド時間は常にひどいものでした。ただし、C++0xが現在よりも遅くなる理由はありません。いつものように、必要なヘッダーのみを含めます。そして、私が知る限り、各ヘッダーは目立って大きくなっているわけではありません。

もちろん、Conceptsはここでの大きな未知数の1つであり、コンパイル時間が大幅に遅くなることが懸念されていました。それが彼らがカットされた多くの理由の1つでした。

注意しないと、C++は簡単に読めなくなります。繰り返しますが、そこには新しいものは何もありません。また、C ++ 0xには、この問題を最小限に抑えるのに役立つ多くのツールが用意されています。ラムダは、たとえばPythonやSMLほど簡潔ではありませんが、今日定義しなければならないファンクターよりもはるかに読みやすくなっています。

移植性に関しては、C++はすでに地雷原です。整数型のサイズや文字列のエンコードについては保証されていません。どちらの場合も、C ++ 0xはこれを修正するためのツールを提供します（Unicode固有のcharタイプ、および保証された固定サイズの整数を使用）

今後の標準では、現在移植性を妨げている多くの問題が明確になっています。

つまり、全体として、そうです、あなたが言及する問題は現実のものです。それらは今日存在し、C++0xで存在します。しかし、私が見る限り、C++0xはこれらの問題の影響を軽減します。それは彼らを悪化させることはありません。

そうです、準拠した標準がすべてのプラットフォームで利用可能になるまでにはしばらく時間がかかります。しかし、C++98よりも迅速なプロセスになると思います。

すべての主要なコンパイラベンダーは、C ++ 0xのサポートに非常に熱心であるように見えますが、前回はそうではありませんでした。（おそらく当時は、すでに実装されている先行標準機能を調整および修正することがほとんどだったため、先行標準コンパイラは「ほぼC++98に準拠している」と主張するのは簡単でした。

全体として、C ++コミュニティは、10年前よりもはるかに標準に焦点を当て、前向きになっていると思います。コンパイラを売りたいのなら、C++0xを真剣に受け止めなければなりません。

しかし、標準がリリースされてから完全に（またはほとんど）準拠したコンパイラが利用可能になるまで、間違いなく数年の期間があります。

于 2009-08-12T17:03:14.557 に答える
10

ほとんどの C++ と同様に、必要なものだけを支払う必要があります。したがって、有用なトラッキング ポインタやスレッド ライブラリなどの「ブースト膨張」が必要ない場合は、コンパイルに料金を支払う必要はありません。

特にboostのようなプロジェクトからの既存の移植可能なコードに基づいているため、移植性は設計で対処されると確信しています. GCC と Microsoft VC の両方には、それぞれの現在のプロトタイプ バージョンからわかるように、C++ 0x の多くが既に実装されています。

于 2009-08-12T15:22:00.503 に答える
6
  1. C++ のコンパイル時間は常に絶望的です。全体の哲学は、実行時にそれを繰り返してパフォーマンスを低下させる必要がないように、1 回実行する (つまり、コンパイル時に実行する) ことです。他の人が言ったように、必要がない場合はライブラリを含めないでください!
  2. C++ は、下位互換性を保つことを目的としているため、あまり Pythonic になることはありません。冗長性は、言語が進化するにつれて多くのことが追加された古い言語であることから来ています。他の人が言ったように、ラムダと自動変数も冗長性を大幅に削減します
  3. これは言語に大きな変更を加えると問題になりますが、変更によって言語が非常に使いやすくなることは広く認められているので、すぐに採用する必要があります。
于 2009-08-12T15:36:08.790 に答える
3

私は実際に、#3 が短期的な最大のリスクだと考えています。私の知る限り、標準では、いくつかの領域（ラムダ）に新しい構文が導入され、以前の単語の意味が変更されています（たとえば、auto）。これらの機能を使用するコードは、展開するすべてのプラットフォームのコンパイラがそれらをサポートしている場合にのみ移植できます。

確かに、これはある時点で起こります。しかし、コンパイラに新しい機能を追加することは簡単なことではなく、かなりの時間がかかります。これらの機能がメイン コンパイラでサポートされるまでに時間がかかりすぎて、プログラマがアーリー アダプターとして移植可能になる能力が阻害されるのではないかと心配しています。

于 2009-08-12T15:22:52.187 に答える
2

多くの場合、C++0xによってコードがはるかに明確になることがわかりました。

可変個引数テンプレートにより、テンプレートの多いコードを処理する場合、ビルド時間を大幅に短縮できます。boost ::は、非常に醜いテンプレートのオーバーロードスキームを使用して、C++98で「可変個引数テンプレート」を実装します。これにより、コンパイル時間が屋根を吹き飛ばされます。リンク

範囲ベースのforループは、読みやすさにも優れています。

C++98っぽいものを考えてみましょう。

for (std::vector<int>::const_iterator itr = vec.begin(); itr != vec.end(); ++itr)
   foo(*itr);

次のように記述できるようになりました（G ++ 4.6で実装）。

for (auto elem : vec)
   foo(elem);

autoキーワードは構文上のノイズも減らします。

ラムダはSTLアルゴリズムでの使用にも最適であり、Cスタイルのコールバック関数やクラス全体を個別に作成する必要がない場合に読みやすくなります。

于 2010-12-24T14:56:54.377 に答える
1

標準的なものの利点の 1 つは、コンパイラがショートカットを使用できることです。is_たとえば、 Xを実装するために必要なブースト テンプレート サーカスは、単純にX<U>に渡すことができれば消えます。これにより、簡単に 2 桁、場合によっては 3 桁節約できます。__compiler__is_<U>

于 2009-08-13T11:41:40.493 に答える
0

ここで質問は何ですか？もちろん、難解なプラットフォームのコンパイラがこれらの機能を実装するまでには何年もかかるでしょう。新しい機能が使えるようになるのは 3 年後、おそらく 5 年後まで期待しないでください。私たちがオランダ語で言うように、「生きてから心配する人」です。

于 2009-08-12T15:22:15.243 に答える