男の子はいましたか？
プログラマーがエラーの原因がコンパイラーであると言ったとき、99％のケースで、それは嘘です。 問題の詳細な調査が始まるとき、原則として、理由は次のとおりです。
- 配列の境界を越える;
- 初期化されていない変数。
- タイプミス;
- 並列プログラムの同期エラー。
- 必要に応じて、不揮発性変数の使用。
- 未定義の動作につながるコードが記述されています。
- などなど。
多くはそのようなエラーの修正を経ました。 それらについてたくさん読んでください。 しかし、これはコンパイラーに致命的な罪を非難することを何度も止めません。 毎回、それは今、それが彼のせいだと思われる。
もちろん、コンパイラーにもエラーが含まれている場合があります。 ただし、マイクロコントローラにエキゾチックなコンパイラを使用しない場合、この可能性は非常に低くなります。 Visual C ++での長年の作業の中で、誤ったアセンブラコードを生成したのは一度だけでした。
ちょっとしたお勧め
コンパイラを非難し、コードまたはフォーラムでそれについて書く前に、詳細な調査を行ってください。 まず、この方法により、コードのエラーをより迅速に除去できます。 第二に、あなたは自分の失態を指摘する他のプログラマーの目には愚かに見えないでしょう。
このメモを書くようになったきっかけ
今日、私はffdshowプロジェクトのコードフラグメントに非常に驚かされました。 ここにあります：
TprintPrefs::TprintPrefs(IffdshowBase *Ideci, const TfontSettings *IfontSettings) { memset(this, 0, sizeof(this)); // This doesn't seem to // help after optimization. dx = dy = 0; isOSD = false; xpos = ypos = 0; align = 0; linespacing = 0; sizeDx = 0; sizeDy = 0; ... }
コメントを見て、私はプログラマーがいかにinしたかを想像しています。 ああ、この厄介なコンパイラ！ デバッグバージョンでは、すべての変数は0です。リリースバージョンでは、最適化が壊れているため、これらの変数はゴミになります。 これは恥です！ 悪い、悪いコンパイラ！
コンパイラをScる、プログラマは非難のコメントを残します。 そして、彼はクラスの各メンバーを個別に無効にする以下のコードを書きます。 悪の勢力に対する勇気の勝利。
そして結局のところ、主なことは、この人がコンパイラのバグに遭遇したという自信を持ち続けるということです。 そして、彼は彼のためにどのように苦しんだか教えてくれます。
誰かが状況のすべてのユーモアを理解していない場合は、説明します。 memset（）関数は、単純なエラーのため機能しません。 3番目の引数は、構造体ではなく、ポインターのサイズを計算します。 正しい呼び出しは、「memset（this、0、sizeof（* this））;」のようになります。
ちなみに、このプログラマーの次には、memcpy（）関数もうまく機能しません。 私は彼がコンパイラ開発者を曲がった手だと考えていると確信しています。
void Assign(const AVSValue* src, bool init) { if (src->IsClip() && src->clip) src->clip->AddRef(); if (!init && IsClip() && clip) clip->Release(); // make sure this copies the whole struct! //((__int32*)this)[0] = ((__int32*)src)[0]; //((__int32*)this)[1] = ((__int32*)src)[1]; memcpy(this,src,sizeof(this)); }
コメントから、彼が別の方法を使用してメモリをコピーしようとしたことは明らかです。 しかし、その後、彼は関数「memcpy（）」を残しました。 おそらく彼女は彼のために64ビットプログラムで働いていたのでしょう。 そこでは、ポインターのサイズは8バイトです。 つまり、8バイト、彼はコピーしたいです。
エラーは再び3番目の引数にあります。 「sizeof（* this）」と言う必要があります。
そのため、バグの多いコンパイラと、それらと戦う勇敢なプログラマーについての伝説が生まれました。
おわりに
何かが機能しない場合は、コードのエラーを探してください。