「チーム全体」のC ++機能

C ++では、例外などの機能はプログラム全体に影響します。プログラム全体でそれらを無効にするか、コード全体でそれらを処理する必要があります。有名な C ++報告書上の記事は、それを置きます：

直感に反して、コーディング例外の難しい部分は、明示的なスローとキャッチではありません。例外を使用することの本当に難しい部分は、任意の例外がスローサイトからハンドラーに伝播できるようにすべての介在コードを記述し、プログラムの他の部分を損傷することなく安全に到着することです。

さえがあるのでnew、例外をスローし、すべての機能が提供する必要がある基本的な例外安全性を - -それは唯一の例外をスローしない保証機能を呼び出しますしない限り、あなた無効に例外がない限り、完全にあなたの全体のプロジェクトでは。

したがって、例外は「プログラム全体」または「チーム全体」の機能です。それらは、それらを使用するチームの全員が理解する必要があるためです。しかし、私が知っている限り、すべてのC ++機能がそのようになっているわけではありません。

考えられる例は、テンプレートを取得していないが、使用していない場合でも、正しいC ++を作成できるかどうかということです。sort整数の配列を呼び出して、その驚くべき速度の利点を楽しむこともできます。Cのqsort（関数ポインターが呼び出されないため）バグを危険にさらすことなく、またはそうしませんか？テンプレートは「チーム全体」ではないようです。

コードを直接使用しないコードに影響を与え、したがって「チーム全体」である他のC ++機能はありますか？Cにはない機能に特に興味があります。

更新：私は特に、あなたがそれらに気づく必要がある言語強制サインがない機能を探しています。私が得た最初の答えはconst-correctnessであり、これもチーム全体であるため、誰もがそれについて学ぶ必要があります。ただし、AFAICSは、マークされた関数を呼び出した場合にのみ影響を与えconst、コンパイラは非constオブジェクトでの呼び出しを禁止するため、Googleに何かを提供します。例外を除いて、あなたはそれを得ることさえしません。さらに、を使用するとすぐに常に使用されるためnew、例外はより「邪魔」になります。ただし、これを客観的に表現することはできないため、チーム全体の機能に感謝します。

更新2：C ++機能の代わりに、大量のメインストリームプログラミング言語に適用されるマルチスレッドのようなものを除外するために、「C ++固有の機能」のようなものを書くべきでした。

付録：この質問が客観的である理由（疑問がある場合）

C ++は複雑な言語であるため、多くのプロジェクトまたはコーディングガイドは「単純な」C ++機能を選択しようとし、多くの人々は主に主観的な基準に従って一部の機能を含めるか除外しようとします。それについての質問は、ここSOで定期的に閉じられます。

上記の代わりに、「可能な限り正確に」「全チーム」言語機能とは何かを定義し、C ++に関する文献の広範な裏付け証拠とともに例（例外）を提供し、C ++でチーム全体の機能を要求します。例外を超えて。

「チーム全体」の機能を使用するか、それが関連する概念であるかは主観的かもしれませんが、それはこの質問の重要性がいつものように主観的であることを意味します。

並行性を「チーム全体」機能として指定します。

少数の専門家だけが並行性の問題を認識する必要があるようにソフトウェアを設計することは可能ですが、チームの他のメンバーは複雑さ（テンプレートでできるように）を気にすることなく利益を享受できますが、実際にはそのように動作しません。実際には、複数のスレッドがある場合、その使用で潜在的な並行性の問題がある場合、使用するすべての変数について慎重に分析する必要があります。

明白な答えはconst正しさです：const/ volatile修飾は感染性であるため、コードの一部が使用を開始すると、すべての（直接または間接的な）呼び出しコードもconst正しくなければなりませんconst。

ただし、例外と同様に、これは明らかに最終的には良いことです。さらに、例外の安全性とは異なり、コンパイラによって厳密に検証されるためです。

ポインター。

• ポインタはスタック上のメモリを指しますか？
• ポインターはヒープ上のメモリを指しますか？
• ポインターは単一のオブジェクトを指しますか？
• ポインターは配列を指しますか？
• ポインターは配列の中央の場所を指しますか？
• ポインターは有効ですか？
• ポインターが壊れていますか？
• どのコードがポインターを「所有」していますか？
• 参照オブジェクトを手動で割り当て解除する必要がありますか？もしそうならどのように？

別の可能性は、演算子のオーバーロードです。コードベースの一部がオーバーロードされた演算子をいじり始めると、誰もが作業している特定のオブジェクトが実際に何をしているかを正確に推測し始める傾向があります。例外やconstの正当性のようにコードベースを介して明示的に伝播するわけではありませんが、いつ、どのように、なぜ使用するかについてチーム全体が同じページにいない場合は、間違いなく問題を引き起こす可能性があります。

思い浮かぶのは、constの正当性（上記を参照）以外に、ストリーミング（状態）だけです。オブジェクトとサブオブジェクトを使用し、オブジェクト階層を使用する可能性のあるC ++コードを記述する場合、最終的にはプログラムのオペレーターとの間でデータを送受信する必要があります。あなたはできる簡単なストリーミング操作書きますコンパイルします意味的に正しいことを...

std::ostream& operator<< (std::ostream&, MyClass const&) {...}
std::istream& operator>> (std::istream&, MyClass&) {...}

...しかし、一度やると、あなたが書き込もうとしている（または最も重要なことは、読んでいる）ものがクライアントがあなたに送っているものと同じ形式に従うという保証はありません。ストリームでは奇妙なケースが多すぎます。関数呼び出しチェーンのストリームとしてストリームまたはストリームフラグを引数として渡す必要がある場合はさらに悪いことになります。これがクラスのストリーミングが通常実装されるものです。したがって、ストリーミングは、上記の用語を使用した場合の「邪魔な」、またはおそらく「バイラル」（_{const-correctnessと同程度ではありませんが）}としても定義できます。

クラス階層の奥深くにメンバーがいstringますか？驚いたことに、クライアントは単一の単語を送信したほうがよいでしょう。シリアル化する番号がありますか？関数を呼び出す前にストリームを8進数出力に設定したばかがわからないため、すべての関数呼び出しの深さでストリームフラグを確認、保存、および復元することをお勧めします。悪くも-ちょうどのようなものと呼ばれる人setfillとsetwし、そのため、あなたの最初の-andの書式設定の入力/出力を破っただけで、それらの状態があるため、あなたの初段の積分メンバーに伝播しません。ああ、ストリームと国際化について尋ねないでください。

正しい方法でストリーミングしているのか、間違った方法でストリーミングしているのか、まったくストリーミングしているという警告は言語にはまったくありません。データバックアップを書き込むために渡すストリームのクライアントコードを要求しましたか？ストリームがを指していることを実際に知る方法はありません/dev/null。（_{一方、そのように信じられないほどのバックアップ速度と圧縮率を要求できます！}）