CとC ++を知っているのに、なぜC ++ 11を学ぶのですか？[閉まっている]

私はCとC ++のプログラマーですが、どちらの言語にも固執せず、2つの混合物を作成します。場合によっては、演算子のオーバーロードやテンプレートを使用したクラス内のコードを使用することもありますが、非常に優れたSTLは明らかに優れた方法です。単純なC関数ポインターを使用すると、はるかに読みやすく、明確になる場合があります。だから、私は両方の言語に美しさと実用性を見出しています。「それらを混ぜてC ++コンパイラでコンパイルすれば、それはもはや混同ではなく、すべてC ++である」という議論には入りたくありません。また、C対C ++については説明しません。この質問はすべてC ++ 11についてです。

C ++ 11では、C ++の動作に大きな変化があると思うものを紹介していますが、さまざまな機能が異なる状況でどのように動作するかを変更する多くの特殊なケース、例外、不規則性を導入し、多重継承、キーワードとして機能する識別子、拡張機能を制限しています文字列リテラル、ラムダ関数変数のキャプチャなど

将来のある時点で、C ++と言うとき、誰もがC ++ 11を想定することを知っています。最近Cを言うときと同じように、おそらくC99を意味します。そのため、C ++ 11の学習を検討します。結局、C ++でコードを書き続けたい場合、同僚が持っているという理由だけで、これらの機能の使用を開始する必要があるかもしれません。

Cを例にとります。何年も経った今でも、Cでコードを学んだり書いたりする人がたくさんいます。なぜですか？言語が良いからです。良い意味は、優れたプログラミング言語を作成するための多くの規則に従っていることです。そのため、Cは強力である（ほとんどすべてのプログラミング言語がそうであるか難しい）ことに加えて、Cは規則的であり、もしあれば例外はほとんどありません。しかし、C ++ 11はそうは思いません。C ++ 11で導入された変更によって言語が改善されているかどうかはわかりません。

質問は次のとおりです。なぜC ++ 11を学ぶのでしょうか。

あなたが仕事を得るために将来それを知る必要があると思うなら、あなたはそれを学ぶべきです。あなたがC / C ++として（そしてあなたが知っているかもしれない他の何でも）あなたが労働力で市場性を保つと確信しているなら、それを学ばないでください。上司からC ++ 11を使用するように指示された場合は、「いいえ、そうしません」と言います。彼があなたを解雇した場合は、どこか別の場所に行きましょう。あなたがすぐにあなたが現在知っているスキルで満足のいく雇用を見つけることができないと予測するとき、C ++ 11を学んでください。

私の理論的根拠を明確にしたかった：私は反C ++ 11ではない。OPの質問を「なぜXを学ぶべきか」に一般化できると言っているだけです。私はCとC ++で仕事をしているので、ML、スキーム、またはhaskellを学んだことはありません。これらの言語は誰かにとって有用であると確信していますが、今すぐ学ぶことは私にとって有益ではありません。誰かがMLでプログラムするのに良いお金を提供してくれたら、それを学ぼうとするかもしれません。

簡単だ。C ++ 11を使用すると、コードが劇的に簡単になり、記述が簡潔になり、高速になります。

nullptrは古いものに対するVAST改善0です。それはタイプセーフであり、そうすべきではないときに変換しません0。に変換されないのは良いことです。それはまったく意味がありません。C ++委員会が検討を試みたときに見つかったことを知っていますか？のようなもの。それはどれほどひどいですか？ので、例外がここにあります唯一の理由はかなりwrong-ですが、前、及びC.でC ++で事実があったことを、整数型、と考えられている変換されていない良い、それはだ偉大な、あなたはそれを愛する必要があります。nullptrint#define NULL nullptrchar c = NULL;boolnullptr

または、右辺値参照と可変長テンプレートはどうですか？より速く、より一般的なコード。それはそこに完全な勝利です。

ライブラリの改善はどうですか？以下のようなものfunction、unique_ptrとshared_ptrされているので、はるかに優れたものを前に、それはC ++ 03の方法が優れていたと主張することは不可能でありますより。

#define adding_func(x, y) ((x)+(y))

リモートでも同等ではありません。マクロは60億の理由で悪いです。ここですべてを引用するつもりはありませんが、マクロは回避できる可能性のあるほとんどすべての目的で回避する必要があることはよく知られています。それが起こったら何をしますか

#define add_twice(x) (x + x)

ああ待って、私はあなたがインクリメントまたは上のものではありませんでした願っていますx。テンプレート関数のバージョンは完全に影響を受けません。また、たとえば名前空間に感謝しないことを願っています。

次に、スコープが既に終了している外部変数を使用するための未定義の動作の世界を開きます。

STLアルゴリズムなどの機能的なAPIでは、参照は問題ありません。保存されたコールバックの場合、値でキャプチャする必要があります。関数に関するドキュメントが何であれ、どれが必要かを明確に示す必要があります。コードがラムダで記述されているという事実は、ローカル変数を参照する問題とは無関係です。通常の関数オブジェクトを渡すと、まったく同じ問題が発生します。そして、それは問題ではありません。まったく。ローカル変数を参照できる場合とできない場合は、本質的に明らかだからです。

Cを例にとります。何年も経った今でも、Cでコードを学んだり書いたりする人がたくさんいます。なぜですか？

朝に歯を磨かない人がたくさんいます。多くの殺人者、強姦犯、売春婦がいます。そして政治家。自殺した人。したがって、それによってこれらの活動が良好または有用になると主張しますか？もちろん違います。誰かがやったからといって、それは良いか、役に立つはずだというのは論理的な誤fallです。

Cはまだ3つの理由で作成されています。C++は、組み込みモードやカーネルモードなどで実装するのが難しいからです。レガシーコードベースはCで記述されており、アップグレードに多額の費用がかかるため、C ++の優れたC相互運用性を考えると、それでも疑問です。そして、それを書いている人々はプログラムする方法を知らないからです。それでおしまい。Cを記述する他の理由はありません。

Cまたは古いスタイルのC ++を使用する場合、多くの例外は見つかりません。

単純な例として、哀れなCスタイルの配列はどうですか？頭の中でまっすぐ配列やポインタを取得できない人の数はわいせつです。C標準ライブラリが非常に安全でないという事実は言うまでもありません。

あなたの核となる議論は、論理的な誤fallと誤解に満ちています。

C ++ 11は新しい言語ではありません。既に知っているのはC ++の拡張/変更のみです。C ++ 11は、他のプログラミング言語と同様に機能で構成されています。それらの多くは以前から存在していましたが、一部は新しいものです。しかし、あなたの質問は本当に、言語のすべての機能（この場合はC ++ 11）を学ぶべきなのか、それとも90％しか知らないのか、ということです。

IMOは、すべての言語を使用していなくても、少なくとも新しい機能が何をするのかを読んでおく必要があります。それらの多くは、ライブラリ/フレームワークコード（特にテンプレート）を簡単に記述できるようにするために導入されました（たとえば、C ++ 11の完全な転送が不可能になる前）。これらの機能がC ++ 11で追加されたことに注意してください。

一方、以前に一部のSTL / Boost機能を模倣するライブラリ/コアコードの作成に手を出し、95％が非常にクールでエレガントなソリューションを手に入れたので、言語によって制限されていることに気付いた場合、言語が単にあなたが望むものをサポートしていないことがわかったので、あなたは止められました。あなたはC ++ 11の本当に素晴らしい力に気付くでしょう。私たちのチームがVS2010にアップグレードしてから（そして、その過程でBoostを発見したので）、r値参照やテンプレートパラメーターの転送などの前には不可能だった、いくつかのクレイジーで素晴らしいコードを作成することができました。

また、ラムダのようなものは外見的に見えるかもしれませんが、新しいコンストラクトを導入しません。代わりに、以前のものが非常に簡単に記述できるようになります。以前は、すべてのラムダ関数は個別のクラスである必要がありました。現在は{... code ...}です。大好きです。

重要なのは、これらの機能を見て、リストがどれほど難しいかを考えないことです。代わりに、通常どおりにC ++を使用し、これらの新しいC ++ 11機能が役立つシナリオに出くわすと（90％を超える人々がそのポイントに到達することはありません）、拡張機能に非常に満足します言語に行われました。とりあえず、言語のすべてを使用する方法とは限らず、何がそこにあるのかを知るのに十分なだけ言語について学ぶことをお勧めします。

関数を書くのは非常に難しいのですか？名前を付けないだけでなく、関数の内容をコードとインラインで記述する必要がありますか？

それを行うときは、上にスクロールするか、新しいソースファイルを開いてそこに関数の定義を追加します。その後、戻って作業を続けなければならず、ある程度気が散ります。

それ以外は、他の人があなたを読んでいるとき、「ああ、この関数は何をするの？」と言うのではなく、ラムダが自己文書化する場合があります。その宣言にジャンプすると、独自の場所で何をしているのかを見ることができます。

ハーブ・サッターによるラムダについてのいい話があります。おそらく彼はあなたをよりよく納得させることができます：

http://channel9.msdn.com/events/PDC/PDC10/FT13

さて、なぜラムダ関数にするのではなく、そこにコードを書いてみませんか？

STLアルゴリズムを使用している場合、または関数を渡す必要がある使用中の関数を使用している場合は実行できないためです。

#defineadding_func（x、y）（（x）+（y））

ラムダの代わりにこの使用法を正当化する方法はありません。どこでもマクロでコードを埋めることはできません。マクロと関数の目的は異なりますが、一般に、一方は他方の代わりではありません。

template<class Lhs, class Rhs>
auto adding_func(const Lhs &lhs, const Rhs &rhs)
                -> decltype(lhs+rhs) {return lhs + rhs;}

同意する、これはいです。しかし、「コンパイラがこれを推測できるのに、なぜこの式のタイプを把握する必要があるのか​​」と言った自分を覚えています。多くの場合。これはそれらの瞬間に大いに役立つかもしれません。

総括する：

C ++ 11の新機能は構文がugいように見えますが、すぐに慣れることができると思います。すべての新しい言語構造は、最初は学ぶのが困難です。クラス全体を書くことを初めて学んだことを想像してください：ヘッダーファイルに宣言を置き、最後に余分なセミコロンを忘れずに、ソースファイルに定義を入れます。複数の包含、メンバー関数宣言などのスコープ解決演算子を忘れないで...

しかし、いくつかのクラスを書いた後、あなたはそれに慣れるでしょう、そしてあなたはこのプロセスの複雑さについて考えていないことはかなり確信しています：クラスはプログラマーとしての仕事をはるかに簡単にし、ユーティリティはあなたがこの新しい構造から稼いでいるのは、あなたが言語を学ぼうとしていた時のユーティリティの損失よりもずっと大きいです。これが、C ++ 11を同様の方法で学習または使用しようとする理由であると考えられます。

実際、OPには、ほとんどの回答に関していくつかのポイントがあります。しかし、それらは視覚において「遠い」ものです。C ++（Cサブセットを含む）には長い歴史があり、多くの機能が時間の経過とともに追加され、それらの一部は多かれ少なかれ頻繁に使用され、他の人や他の人に完全に使用されました。

新しい機能を導入した後、古い機能が必要になったり、それと矛盾したりすることがあります。「クリーンな」言語はそのまま一貫したものでなければならず、もはや必要な機能を削除すべきではありません。

しかし、追加しても何も破壊されません。削除（または変更）は、まだ運用中の既存のコードを破壊するため、追加する機能が何であれ、既存のコードを破壊しないように注意する必要があります（特に、意図せずに別のことをするように黙って破壊しないでください））。

そのすべてを学ぶ必要がありますか？はい。すべての機能は、良くも悪くも、遅かれ早かれ使用されるためです。これが言語の「品質」にとって良いものかどうか（客観的な尺度があることを認める）は、別の話です。後方互換性はどれくらいの期間保持されるべきでしょうか？誰かが3年と言い、他の人が50と言うとき、答えを見つけるのは難しい。

C ++をより「通常」に保つための代替手段は、...スクラッチを再起動して、より頻繁に中断することです。しかし、もはやC ++ではなくなります。

同様にそれを行う試みもあります（たとえば、Dを考えてみてください：実際にはC ++（11でも）とはるかに直交しています）が、それらはどれほど人気が​​ありますか？勢いを持つのが難しい理由の1つは、まだ実行する必要がある多くの既存のコードとの非互換性です。

私にとって、C ++ 11は明らかに、新しいニーズと下位互換性の間の妥協点です。その結果、仕様と実装に特定の「混乱」が生じました。その「乱雑さ」のコストが非互換性のコストよりも小さくなるまで...あなたはその妥協に任せなければなりません。

あなたがそれをもう許容できない場合は、...別の若い言語を検討する方が良いでしょう。その意味では、C ++は単純化できません。この年齢ではありません。

新しいC ++ 11機能を無視することにした場合でも、C ++標準ライブラリがそれらを使用するため、これらの機能を利用できます。たとえば、型の変数を持つC ++ 98ではvector<string>、ベクトルが大きくなったときにコピーの数を作成する必要があるため、パフォーマンスが低下する可能性がありました。C ++ 11移動コンストラクターでは、これは問題ではありません。実際、C ++ 11がより多くの新機能をもたらしました。特に標準ライブラリではそうでした。

何年も経った今でも、Cでコードを学んだり書いたりする人がたくさんいます。なぜですか？言語が良いからです。

第一に、最近のほとんどの学生はCではなくJavaまたは.NETを学んでいます。第二に、人々はまだ言語としての利点だけでなく、主にCで書かれた膨大な量の既存のソフトウェアがあるためにCを使用しています多くの場合（組み込みプラットフォームなど）、Cコンパイラがすべて揃っているため、維持および拡張されます。ちなみに、これらは人々がまだCOBOLを書く理由の一部です。

業界のプログラマーが、既存のコードベースに縛られていないまったく新しいプロジェクトで作業を開始し、単独で作業を続けることは非常にまれです。そのため、C ++ 11を学習する理由は、新しい機能を使用する他の人が作成したコードを処理しなければならない可能性が高いためです。また、追加された機能は理由のために追加されました。それらを学習して使用すると、それらに感謝するようになるかもしれません。

• 人々はマシンコードを書くことを好まなかったため、アセンブリが作成されました
• Cは、人々がアセンブリを書くことを好まなかったために作成されました
• C ++は、人々がCを書くことを好まなかったために作成されました。
• C ++ 11が作成されたのは、人々がC ++を書くのが好きではなかったからです

C ++のキャリアの中で、「ファンクターがもっとシンプルになったらいいのに」とか、「なぜNULLはintなのか」と言うところまで来ます。そして、C ++ 11を理解します。

学習は常に有益です。知識は力である。

それが基本的な答えです。それ以外はすべて、それからどれだけ正確に利益を得ることができるか、そしてそれを知ることで得られる力についての詳細であり、列挙が不完全であるほどたくさんあります。

1つの例はあなた自身の質問です。少なくとも少し学習しなければ、質問することさえできません。

そして、私がコメントしたように-本当の懸念は学ぶ理由ではなく、使用する理由です。それはまったく別の質問です。

追加された機能により、より良いコードを作成できるため、C ++ 11を学習する必要があります。NULLポインターとラムダの型安全性について言及している人もいますが、これらは非常に便利です。しかし、特に大規模な実稼働環境でのC ++ 11の最も劇的な変化であると思うものに注意を向けたいと思います。それは、セマンティクスの移動です。

C ++ 11は、「移動」と「コピー」の別々の概念をサポートしています。通常のC ++では、基本的にこれらの両方を行う=演算子があります。しかし、実際には、1人のオペレーターで2つの異なるアイデアを表現しているため、危険です。

これが役立つ最も明白な例は、新しいunique_ptrです。古いauto_ptrとscoped_ptrの最高の機能をすべて備えています。オブジェクトを指す唯一のポインタであることが保証されているポインタが必要だとします。a = bをどのように扱いますか？さて、前に行き詰まってしまいました（scoped_ptrとして）完全に禁止するか、a = bがbから所有権を奪うところでauto_ptrができることをすることができます。auto_ptrのこの動作は、a = bが実際にbを変更するため、非常に混乱します。unique_ptrはこれを処理します。a= bは許可されませんが、所有権を盗むためにa = std :: move（b）があります。これはどのように役立ちますか？ここで、コピーセマンティクスではなく移動セマンティクスを使用する別の（オーバーロードされた）バージョンのスワップがあります。これは、unique_ptrを問題なく交換できることを意味します。つまり、unique_ptrは、auto_ptrとは異なり、コンテナ内で使用してからソートと言っても安全です。unique_ptrは、基本的にbe allであり、同じオブジェクトに複数のポインターが必要ない場合、すべての安全なメモリ管理を終了します。

別の素晴らしい例：コピーできないオブジェクトがあるとします。これは多くの状況で役立ちます。関数が終了すると、返されるものはすべてコピーされるため、関数からこのオブジェクトを返すことはできません。皮肉なことに、通常、コンパイラは実際にこれを最適化します（つまり、実際には最後に何もコピーされず、最終的な割り当てのアドレスに戻り値が作成されます）。しかし、これはコピー不可にした理由とは何の関係もありません。関数から戻ることは、実際にはオブジェクトを関数のスコープ内から外部に移動するだけです。コピーできないが移動可能なオブジェクトを作成できるようになりました。これらのオブジェクトは関数から返すことができます。

移動セマンティクスを使用すると、リークせず、スレッドセーフなコードを簡単に作成できます。