declaration of 'a' hides global declaration at line 6 Test.mq4 1314
declaration of 'b' hides global declaration at line 6 Test.mq4 1322
Visual Studio 2012、コード解析を含む - 何もない。 潜在的なエラーの解析の質はゼロだ。昔からライバルがいないので、悩まないのでしょう。
PVS Studio - 正しくレポートします。
V669 The 'a', 'b' arguments are non-constant references. The analyzer is unable to determine the position at which this argument is being modified.
It is possible that the function contains an error. test.cpp 17
int a=1,b=2;
//--------------------------------------------------------------------void start(){
int k=sum(a,b);
Alert(k);
}
//--------------------------------------------------------------------int sum(constint& a, constint& b){
return(a+b);
}
int a=1,b=2;
//--------------------------------------------------------------------int sum(int& a, int& b){
return(a+b);
}
//--------------------------------------------------------------------int main(){
return sum(a,b);
}
コンパイルとコンパイラーメッセージ
$ icpc -c -Wremarks 1.cpp
1.cpp(3): remark #1418: external function definition with no prior declarationint sum(int& a, int& b){
^
1.cpp(3): remark #3280: declaration hides variable "a" (declared at line 1)int sum(int& a, int& b){
^
1.cpp(3): remark #3280: declaration hides variable "b" (declared at line 1)int sum(int& a, int& b){
^
int a=1,b=2;
//--------------------------------------------------------------------void start(){
int k=sum(a,b);
Alert(k);
}
//--------------------------------------------------------------------int sum(constint& a, constint& b){
return(a+b);
}
インテル® C++ 15.0.0 コンパイラーは、-Wremarks オプションを指定してコンパイ ルした場合、どちらのケースでも同じコメントを生成します。
Vininさん、こんにちは。
AltrTrend_Signal_v2_2.mq4 を確認しました。
で、論理エラーを発見
式中 : SSP=MathCeil (Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1))
最後に1という下線が入っていますね
は、どうあるべきだと思いますか?
パンサー
おそらく0!(笑ループの場合は、i などでカウントしてみてください。
Vininさん、こんにちは。
AltrTrend_Signal_v2_2.mq4 を確認しました。
で、論理エラーを発見
式中 : SSP=MathCeil (Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1))
最後に1という下線が入っていますね
は、どうあるべきだと思いますか?
パンサー
マストシフト
このエディターは、C言語の標準に従って、この標準的で合法的で一般的な構成に対して、次のような警告を生成します。「4行目で 'a' の宣言がグローバル宣言を隠す」、「4行目で 'b' の宣言がグローバル宣言を隠す」これは、関数内に新しい変数の宣言も、変数の重複を示唆するものもないため、コアによっても不適切で無識なものです。
その結果、それほど大きくないプログラムコードでも、無関係な警告が何百と出てくることになります。
メッセージは、まったく100%正しい。
コンパイラを深く制御することの有用性を理解するには、自分のコードに全責任を持つプログラミングを5年から10年、積極的に行う必要があります。C/C++言語が自己流で名声を得たのは、品質を深く分析し、作者を保護する気がなく、できなかった弱いコンパイラのせいも少なからずある。
2014年の今でもC/C++コンパイラ(マイクロソフトに完全に潰されてWindowsに残ったもの)は、プログラマーを自分から守るためのビジネスにはなっていない。そうそう、Visial Studioでコード解析を別途実行し、お金をかけても、PVS Studio(神をたたえよ)、CPP Check、Lintを別途使って、深いエラー検索をしなければならない弱点(実質的に役に立たない)があります。
この例をテストします。
私たちの課題は、品質管理に優れ、C/C++言語の自殺行為/非常識な技術を許さない高品質のコンパイラを作ることです。
また、メッセージは全く意味がないと思っています。私はプロのプログラマーではありませんが、µlのこのような無意味なことはストレスになります。aとbへの参照が一定である場合、PVS Studioは警告を発生させるのでしょうか(自分で確認する方法がない)。
この例のテスト。
1.この単純なコードで、コンパイラが警告するような潜在的なエラーとは具体的にどのようなものなのか、例を挙げて教えてください。
プログラマーへの配慮は、合理的な論理的説明があり、邪魔にならない程度であれば、確かに良いことだと思います。
2.書かれたコードの品質は、コンパイラの品質や構文解析の能力とは関係なく、書かれたコードの深い機能解析を行うことができるテスト環境が十分に書かれている場合にのみ発生するものだと思うのです。しかし、テストシェルなしでコードの構文解析を節約することを信じるのはユートピアであり、努力の無駄である。
そのため、プロのプログラマーはほとんど警告を見ません。コンパイラーは定義上、コードの機能解析を行うことができませんし、初心者のプログラマーでも とりあえず言語の構文を知っているからです。
メッセージは、まったく100%正しい。
それらは正しいのですが、実用的ではありません。また、このコンパイラの挙動を制御できないことも非常に重要である。
コンパイラの深層制御の有用性を理解するためには、自分のコードに全責任を持つプログラミングを5〜10年続ける必要があります。C/C++言語が自己流で名声を得たのは、品質を深く分析し、作者を保護する気がなく、できなかった弱いコンパイラのせいも少なからずある。
MQL4/MQL4+/MQL5では、なぜこれらの言語をベースにしたのでしょうか?
結局、そもそもコンパイラの話ではなく、その言語の設計の話なんです。
2014年の今でも、C/C++コンパイラ(マイクロソフトに完全に潰されてWindowsに残っているもの)は、プログラマを自分から守るためのビジネスにはなっていない。そうそう、Visial Studioでコード解析を別途実行し、お金を出せば、弱い(実質的に役に立たない)コード解析もありますが、深いバグを見つけるには、やはりPVS Studio(あの人たちをほめる)、CPP Check、Lintを別途使用しなければなりません。
この例のテスト。
第一に、マイクロソフトは全知全能ではなく、ユビキタスでもない。そして2つ目は、Windowsには他のコンパイラが残っていることです。Linux環境からコンパイルしていますが、一例を挙げると、このコンパイラのWindows版とLinux版では、「深いエラー検索」の部分に違いはありません。ソースコードに若干の修正を加えています。
コンパイルとコンパイラーメッセージ
2014年のWindowsコンパイラには、「ディープサーチ」というサービスがあるんですね。
なお、「深層検索」を使うかどうかの判断はプログラマーに委ねられている。「-Wremarks」オプションなしでより実用的なコンパイルをした同じコードでも、「-Wall」オプションですべての警告を有効にするとコメントなしでコンパイルできるようになる。
$ icpc -c -Wall 1.cpp $
さらに、このコンパイラでは、プログラマーが不要と考える発言を無効化するなど、個々の発言のレベルで「深層心理」を制御することができる。
コンパイラは以下のバージョンを使用します。
ちなみに、このコンパイラはVisual Studioと統合されており、少なくとも以前のバージョンでは、Visual Studioと統合されていたようです。
私たちの課題は、品質管理に優れ、C/C++言語の自殺行為/非常識な技術を許さない高品質のコンパイラを作ることです。
質の高いコンパイラは、まず第一に「動く」こと、つまり言語の定義に対応していなければならず、そうでなければ他のすべての機能が意味を失ってしまう。
privateセクションで宣言されたf()メソッドは、本来ならスタティックメソッドから完璧に呼び出されるのに、同じくprivateセクションで宣言されたクラスコンストラクタは、変数定義の際に同じスタティックメソッドから「呼び出されない」のはなぜでしょうか?
エラーメッセージを表示します。
このコンパイラのバグにより、例えばMyersのシングルトンを人間的に実装することはできません(この例は、当該シングルトンの実装ではありません)。また、プライベートセクションで宣言されたエンティティへのアクセスに関しては、今回が最後のバグではありません。
これはまさにバグであり、例えば自殺行為や理不尽なテクニックに対して向けられた機能ではありません。なぜなら、自動変数定義を動的オブジェクト生成に置き換えると、コンストラクタは突然最も素晴らしい方法で呼び出されるからです。
このコードは、すでにエラーなくコンパイルされています。また、コンストラクタのコードから何らかのメッセージのプリントアウトを挿入することで、この場合のコンストラクタがすでに呼び出されていることを確認することができます。
このようなバグが残っている限り、品質の良いコンパイラと言うのはおかしいのです。言語実装自体のエラーに関しては、商用・非商用を問わず、C/C++コンパイラの方がMQL4+コンパイラよりもはるかに優れており、そのような無意味なものは存在しないためです。これと比較すると、MQL4+コンパイラは「全く機能していない」と言えるほどです。
MQL4+コンパイラの唯一の特徴は、プログラマが失敗する可能性のある関数(例えば取引関数)の戻り値を制御していない場合に警告を出すことです。しかし、このような強力なコンパイラの機能であっても、その実装の質が低ければ、その価値は非常に限られたものになる。
また、メッセージは全く意味がないと思っています。私はプロのプログラマーではありませんが、µlのこのような無意味なことはストレスになります。aとbへの参照が一定である場合、PVS Studioは警告を発生させるのでしょうか(自分で確認する方法がない)。
忠実ではあるが、実用的ではないのだ。
まあ、潜在的なエラーの指摘が正しいのであれば、これらのエラーは修正されなければなりません。 。
潜在的なエラーは、あくまでも潜在的なエラーであって、必ずしもエラーであるとは限りません。したがって、「これらのエラーを修正しなければならないということだ」というのは誤りです。
ほぼ確実にエラーが発生するケースもあります。例えば、関数呼び出しの 結果を確認しない場合、失敗する可能性があります。このような場合の警告は適切であり、かなり有用である。エラーかどうかはっきりしない場合の警告は、通常、無関係であり、有用ではありません。名前が伏せられている時点で、ほぼ間違いないとは言い切れない。
そう、プログラマーは潜在的なエラー、つまり不注意で作ったエラーがないかどうか、「ディープサーチ」ベースであらゆる種類の診断を受けることが可能なのです。しかし、これはメインコンパイラのモードであってはならないし、無効にすることも可能でなければならない。このような潜在的なエラーから初心者を守るため、インストール後、デフォルトで診断機能を有効にすることができます。しかし、それでもオフにすることができるはずです。
外側のスコープで宣言された名前を内側のスコープで隠した場合、インテル・コンパイラーは警告ではなく、単なる指摘として検出します。また、他のコンパイラ(非商用も含む)では、このような隠蔽の事実があっても、警告には対応しません。なぜなら、コンパイラのユーザー、つまりプログラマーの経験をすべて集約すると、これは警告であってはならないことだとわかるからです。また、当然ながら、どの警告/備考を発行し、どの警告/備考を発行しないかをユーザーが設定できるようにする必要があります。
ところで、MQLはC/C++の標準に従ってはいけない別の言語なので、囲んだスコープ内の名前の隠蔽を無効にするのは簡単ではないでしょうか?
この発言は無意味であり、原則としてプログラマに有益な情報を与えない。なぜなら、最初に述べたように変数 "a "の隠蔽は存在しないからである。
変数のローカルコピーが作成されたときのみ隠蔽が発生しますが、これも正当な動作です。この隠蔽により、コードに突然エラーが発生しても、すぐに同じ名前で検索されるため、まさに簡単に見つけることができるのだ。もし、このルールをコンパイラの論理で「解決」するために、関数テンプレートの名前を変更・改変し始めたら、エラー検索の 状況はもっと複雑になり、コードの理解に混乱が生じるでしょう。当たり前のようですが。