テンプレート・パラメータ = void* のコンパイラ・バグ - ページ 10

新しいコメント
 
Ilya Malev:
普通のプログラマーは、C++の演算の優先順位を 掛け算表のように覚えている」ことについては
そんなテーゼを口にした人はいない。私自身は、Documentationのタブを利用しています
 
fxsaber:

そのとおりです。全然プロじゃない、こんな警告に100回助けられた。

私はプロではありませんが、このような警告に何度も悩まされました。何十（時には何百）もの余計な警告の中で、本当に重要で必要な警告が失われてしまったからです

また、あらゆるところに括弧をつけた場合、どのような警告が出るかは不明です？また、他の事件に関するものであれば、混同する必要はないでしょう

 
A100:

そのコンセプトをコンパイラに実装できるように。余計な括弧をつけることを禁止している人はいない。質問は、不要な警告についてです

さて、スタジオではこれを水準器で構成しています。

そして実際、コンパイラが好むようにコードを変更することで、これらの警告を除去することは誰にも妨げられません。

 
TheXpert:

まあ、スタジオでは 水準器によって設定 されているんですけどね。

また、コンパイラが好むようにコードを変更することで、これらの警告を除去することは、実際には誰も妨げていません。

そうすると、余計な括弧がつくので邪魔なんです。しかし、この目的の愛好家が余計な括弧をつけることを誰も妨げないし、最も重要なことは、誰もがそれで満足することである。

スタジオで設定可能か どうかは疑問です。なぜなら、（少なくともデフォルトでは）括弧を忘れたとされる冗長な警告はなく、したがって設定する対象もありません。

 
A100:

私は気にしません。これらの警告は古いMQL4のままにしておいてください。

そうやって、ほとんどの場合、残っているのです

void OnStart()
 {
  int a=0,b=0,c=0,d=0,e=0,f=0;
  a=b|d/e^f|a^b&d^e%f|c;
 }

μl4では全てに悪態をつきますが、μl5では << と >> の操作にのみ悪態をつきます。これは非常に論理的で、これらのオーバーロードの論理は、それらが優先された論理と非常に異なることがほとんどだからです。これらの警告に何度も助けられたし、少なくともあまり迷惑はかけなかった。まあ、それと&&や｜｜コードの論理を定義する論理演算は、どうせなら括弧で区切った方がいいんだけどね...。

 
A100:

私もプロではありませんが、このような余計な警告が何十回も（時には何百回も）出てきて、本当に重要で必要な警告を見失ったことが何度もあります

また、あらゆるところに括弧をつけるとどのような警告が出るかは不明ですが？また、他の事例についてであれば、すべてをひとくくりにする必要はないでしょう

通常は、ある状態をすぐに修正しなければならないようなことが起こります。例えば、ある条件で&&と書いてしまい、｜｜に置き換えるべきところを間違えてしまった。訂正してF7を押しました。すぐに警告が出ました。正確に見ると、現在の変更点での結果は、私が期待したものではありません。修正しました - すべて正常です。つまり、コンパイラのメッセージにとても助けられたのです。


しかし、もし警告が一杯出るようなら、もっと丁寧にコードを書いてください。それとも、機械が間違っていることを証明するために、主義主張として編集しないのですか？

 
A100:

無駄な括りができてしまうので、それを防ぐためです。しかし、このビジネスの愛好家のために余分なブラケットを置くことは誰にも迷惑をかけませんし、最も重要なのは、誰もがそれで構わないということです。

スタジオで設定可能か どうかは疑問です。なぜなら、（少なくともデフォルトでは）括弧の付け忘れ疑惑に関する余計な警告が出ないので、設定の対象がないのです

まったくもって同感です。プログラマーを名乗るからには、操作の優先順位くらいは覚えておいて ほしいものだ。最近、ロボットの追加を依頼されたのですが、init()とstart()の追加を依頼され、いつ書いたのかと聞くと、1週間前と言われました。だから、まだ「コーダー」がいるのですが、そういう人には不要な警告を残す価値はない。

 
Vladimir Simakov:

全く同感です。プログラマーを名乗るからには、親切心で操作の優先順位くらいは覚えておいて ください。最近、ロボットを書き終えてくれと言われたのですが、そこにはinit()とstart()があって、いつ書いたのかと聞くと、1週間前と言われました。だから、まだ「コーダー」がいるのですが、そういう人には不要な警告を残す価値はない。

優先順位の知識は警告とは関係ない。黙々とコードを書き、プログラマーを名乗らない。

 
A100:

スタジオに設置 されているかは疑問ですが

あるプロジェクトでは、リリースバージョンの警告をすべて修正する、という鉄則がありました。

https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2017

警告は多ければ多いほどいいと思います。

 
fxsaber:

警告の数が膨大な場合は、コードをより丁寧に書いてください。それとも、機械が間違っていることを証明するために、原則通り訂正しないのでしょうか？

私はほとんどC++互換のコードを使っています（1つのファイルでもよくあります）。C++にはそれがなく、不要な括弧は、すでにここで 気づいたように、理解を難しくする

1...34567891011121314151617...20
新しいコメント