関数が誤って参照パラメーターを無効にします-何が間違っていましたか？

今日、特定のプラットフォームでのみ断続的に発生する厄介なバグの原因を発見しました。要約すると、コードは次のようになりました。

class Foo {
  map<string,string> m;

  void A(const string& key) {
    m.erase(key);
    cout << "Erased: " << key; // oops
  }

  void B() {
    while (!m.empty()) {
      auto toDelete = m.begin();
      A(toDelete->first);
    }
  }
}

この単純化されたケースでは、問題は明らかなように見えBます。キーへの参照を渡してA、マップエントリを削除してから印刷しようとします。以来、これはもちろん、未定義の動作である（私たちの場合は、それが印刷されなかったが、より複雑な方法で使用される）keyへの呼び出し後にダングリング参照ですerase。

これを修正するのは簡単でしconst string&たstring。パラメータタイプをからに変更しました。問題は、そもそもどうやってこのバグを回避できたのでしょうか？両方の機能が正しいことをしたようです：

• Akey破壊しようとしているものを参照していることを知る方法がありません。
• Bに渡す前にコピーを作成できたかもしれAませんが、値または参照によってパラメータを取るかどうかを決定するのは呼び出し先の仕事ではありませんか？

従わなかったルールはありますか？

Akey破壊しようとしているものを参照していることを知る方法がありません。

これは事実ですAが、次のことを知っています。

1. その目的は何かを破壊することです。

2. それは、破壊するものとまったく同じタイプのパラメーターを取ります。

これらの事実を考えると、パラメーターをポインター/参照として使用する場合、独自のパラメーターを破棄することが可能ですA。これは、そのような考慮事項に対処する必要があるC ++の唯一の場所ではありません。

この状況は、operator=割り当て演算子の性質が、自己割り当てについて心配する必要があることを意味する方法と似ています。this参照パラメーターのタイプとタイプが同じであるため、これは可能性です。

A後で問題を使用するつもりであるため、これは問題があるだけであることに注意してくださいkeyエントリを削除した後パラメーターください。そうでなければ、それは問題ないでしょう。もちろん、その後、すべてが完全に機能Aするようkeyになり、潜在的に破壊された後に誰かが使用するように変更します。

それはコメントのための良い場所でしょう。

従わなかったルールはありますか？

C ++では、盲目的に一連の規則に従えば、コードは100％安全であるという前提の下で操作することはできません。私たちにはルールがありませんすべての。

上記のポイント2を検討してください。Aキーとは異なるタイプのパラメーターを使用できますが、オブジェクト自体はマップ内のキーのサブオブジェクトになる可能性があります。C ++ 14では、findそれらの間に有効な比較がある限り、キータイプとは異なるタイプを使用できます。その場合m.erase(m.find(key))、パラメータのタイプがキータイプではない場合でも、パラメータを破棄できます。

そのため、「パラメーターの種類とキーの種類が同じ場合、値で取得する」というようなルールはあなたを救いません。それ以上の情報が必要になります。

最終的には、経験に基づいて、特定のユースケースと運動判断に注意を払う必要があります。

はい、あなたを破ったかなり単純なルールがあります。それは単一の責任原則です。

現在、Aマップからアイテムを削除するために使用するパラメーターと、他の処理行うれます（上記のように印刷、実際のコードでは明らかに何か）。これらの責任を組み合わせることは、問題の原因の多くのように思えます。

我々はそれがいることを一つの関数がある場合は、単にマップから値を削除し、別のことばかりマップから値の処理を行いますが、我々は、より高いレベルのコードからそれぞれを呼び出す必要があるだろうので、我々はこのようなものに終わるだろう：

std::string &key = get_value_from_map();
destroy(key);
continue_to_use(key);

確かに、私が使用した名前は間違いなく実際の名前よりも問題を明らかにしますが、名前に意味がある場合は、参照を使用し続けていることを明確にすることはほぼ確実です無効化されました。コンテキストの単純な変更により、問題がより明確になります。

従わなかったルールはありますか？

はい、機能の文書化に失敗しました。

パラメーターを渡すコントラクトの説明がない場合（特にパラメーターの有効性に関連する部分-関数呼び出しの開始時または全体）、エラーが実装にあるかどうかを判断することはできません（呼び出しコントラクトの場合呼び出しの開始時にパラメーターが有効であるため、関数はパラメーターを無効にする可能性のあるアクションを実行する前にコピーを作成する必要があります（呼び出しコントラクトがパラメーターを呼び出し中有効のままにする必要がある場合、呼び出し元はできません）変更中のコレクション内のデータへの参照を渡します）。

たとえば、C ++標準自体は次のことを指定しています。

関数への引数に無効な値がある場合（関数のドメイン外の値や、その使用目的に対して無効なポインターなど）、動作は未定義です。

ただし、これは呼び出しが行われた瞬間にのみ適用されるか、関数の実行全体に適用されるかを指定できません。ただし、多くの場合、後者のみが可能であること、つまり、コピーを作成しても引数を有効に保つことができない場合は明らかです。

この区別が関係する現実世界のケースはかなりあります。例えば、自身にa std::vector<T>を追加する

従わなかったルールはありますか？

はい、正しくテストできませんでした。あなたは一人ではなく、あなたは学ぶための適切な場所にいます:)

C ++には多くの未定義の動作があり、未定義の動作は微妙で迷惑な方法で現れます。

おそらく100％安全なC ++コードを書くことはできませんが、多くのツールを使用することで、コードベースに誤って未定義の動作を導入する可能性を確実に減らすことができます。

1. コンパイラの警告
2. 静的分析（警告の拡張バージョン）
3. インストルメント済みテストバイナリ
4. 強化されたプロダクションバイナリ

あなたの場合、（1）と（2）が大いに役立つとは思いませんが、一般的にはそれらを使用することをお勧めします。今のところ、他の2つに集中しましょう。

gccとClangはどちらも-fsanitize、さまざまな問題をチェックするためにコンパイルするプログラムを計測するフラグを備えています。-fsanitize=undefined例えば、あなたの特定のケースで...など、高すぎる量でシフトし、整数アンダーフロー/オーバーフローを締結したキャッチします、-fsanitize=addressと-fsanitize=memory問題にピックアップしそうだっただろう...あなたは関数を呼び出すテストを持って提供します。完全を-fsanitize=thread期すために、マルチスレッドのコードベースがある場合は使用する価値があります。バイナリを実装できない場合（たとえば、ソースのないサードパーティのライブラリがある場合）、valgrind一般的には低速ですが使用することもできます。

最近のコンパイラには、富を強化する可能性もあります。インストルメント済みバイナリとの主な違いは、強化チェックがパフォーマンスへの影響が小さく（1％未満）なるように設計されており、一般に本番コードに適していることです。最もよく知られているのは、制御フローを破壊する他の方法の中でも特に、スタックスマッシング攻撃や仮想ポインターハイジャックを阻止するように設計されたCFIチェック（制御フローの整合性）です。

（3）と（4）の両方のポイントは、断続的な障害を特定の障害に変換することです。どちらもフェイルファーストの原則に従います。この意味は：

• 地雷を踏むといつも失敗する
• それはすぐに失敗し、ランダムにメモリを破損するのではなく、エラーを指摘します...

（3）を適切なテストカバレッジと組み合わせることで、ほとんどの問題が本番稼働前にキャッチされるはずです。本番環境で（4）を使用すると、迷惑なバグと悪用の違いになります。

@注：この投稿では、Ben Voigtの回答に加えて、さらに引数を追加しています。

問題は、そもそもどうやってこのバグを回避できたのでしょうか？両方の機能が正しいことをしたようです：

• Aは、キーが破壊しようとしているものを指していることを知る方法がありません。
• Bは、Aに渡す前にコピーを作成することもできましたが、値または参照によってパラメーターを取るかどうかを決定するのは、呼び出し先の仕事ではありませんか？

両方の関数は正しいことをしました。

問題はクライアントコード内にあり、Aを呼び出す副作用を考慮していません。

C ++には、言語の副作用を直接指定する方法はありません。

これは、副作用などのことをコードで（ドキュメントとして）確認し、コードで維持すること（おそらく、前提条件、事後条件、および不変条件のドキュメント化を検討する必要があること）同様に、可視性の理由からも同様です）。

コード変更：

class Foo {
  map<string,string> m;

  /// \sideeffect invalidates iterators
  void A(const string& key) {
    m.erase(key);
    cout << "Erased: " << key; // oops
  }
  ...

この時点から、APIの上に、ユニットテストが必要であることを伝える何かが表示されます。また、APIの使用方法（使用しない方法）も説明します。

そもそもどうしてこのバグを回避できたのでしょうか？

バグを避ける方法は1つしかありません。コードの記述を停止することです。他のすべては何らかの形で失敗しました。

ただし、さまざまなレベル（単体テスト、機能テスト、統合テスト、受け入れテストなど）でコードをテストすると、コードの品質が向上するだけでなく、バ​​グの数も減ります。