エラー、バグ、質問 - ページ 1968 1...196119621963196419651966196719681969197019711972197319741975...3185 新しいコメント pavlick_ 2017.08.20 17:56 #19671 ヘッダファイルに書くと「#import宣言がありません」というくだらない無駄な警告が出るのはなぜ?void f(); void f() {}まともなところでは、申告の回数に制限はない。mqhヘッダに利用可能な機能を簡単に記述したい場合、行をコメントしなければならず、可読性に悪影響が出るので困る。静的メソッドは クラスか構造体に入れろ(構造体を使うと「構造体にはメンバがありません、サイズは1バイトに割り当てられています」という素晴らしい警告が出ます)」という人もいるかもしれません。私は、このようなグーピーの警告の洪水なしに、「私はμlクラスが好きではありません、最初のオプションを使いたいのです」と答えます。なぜ、完全に有効な常識を放棄することを強要するのですか? A100 2017.08.20 20:02 #19672 pavlick_:ヘッダーファイルに書くと「#import宣言がありません」という警告が出るのに、なぜこのような愚かで無駄なことをするのでしょうか。これは特殊なケースです。より一般的なソリューションとして、アナログを追加することは理にかなっています。#pragma warning (disable:xxxx) で、経験豊富なプログラマーなら誰でも、この煩わしい警告を無効にすることができます(その番号はコマンドコンパイラで確認できます)。既存の警告システムは基本的に役に立たない...。プログラマーの書き方や経験を考慮していない同じようなものが何百とあるので、目も通しません。そして、これらの何百もの警告の中から、注意を払うに値する本当に重要な警告を見つけるのは難しい。 A100 2017.08.20 20:11 #19673 class A { public: A() { Print( A::a ); } //Результат: 0 static const int a; }; /* ... */ const int A::a = 1; 信じられない?明日、コードを追加してみます pavlick_ 2017.08.20 20:20 #19674 A100:これは特殊なケースです。より一般的なソリューションとして、アナログを追加することは理にかなっています。 そして、経験豊富なプログラマーなら誰でも、煩わしい警告を無効にすることができます(その数は、コマンドコンパイラで確認できます)。既存の警告システムは基本的に役に立たない...。プログラマーの書き方や経験を考慮していない同じような警告が何百とあるので、目を通すこともありません。そして、その何百もの中から、注意を払うに値する本当に重要なものを見つけるのは難しい。 はい、そうですね。でも、警告は一度にまとめて管理したほうがいいと思うんです。キーメカニズム(-Wno_all など)または #pragma warning (level:{0|1|2|...}) です。1つずつ無効化するのは面倒だ。 削除済み 2017.08.21 08:55 #19675 開発者の皆様へインジケータの計算が サブウィンドウにあり、そのバッファのいくつかのスタイルがDRAW_NONEである場合、それらはサブウィンドウの表示スケールに影響を与えないという事実について、編集があったことを思い出してください。それとも、そのような編集はなかったのでしょうか?もし、そのような変更をしていないのであれば、ぜひ、変更してください。なぜなら、DRAW_NONEスタイルがサブウィンドウのグラフィックに影響し、全く異なるスケールであるべきだということがわかったからです TheXpert 2017.08.21 09:08 #19676 pavlick_: はい、そうですね。ただ、私は警告のセットを一度に管理する方が良いと思います。キーメカニズム(-Wno_allなど)または#pragma警告(レベル:{0|1|2|...})を使用します。1つずつ無効化するのは面倒だ。おそらく何年も前から、警告やエラーのたびに、なぜそれが出てくるのかが明確にわかるような例を求めてきたのでしょう。このように考えると、階層化やワラントの明示的な管理は幻想のように見えてきます。 Stanislav Korotky 2017.08.21 10:33 #19677 Alexey Kozitsyn:開発者の皆様へインジケータの計算が サブウィンドウにあり、そのバッファのいくつかのスタイルがDRAW_NONEである場合、それらはサブウィンドウの表示スケールに影響を与えないという事実について編集されていたことを思い出してください。それとも、そのような編集はなかったのでしょうか?もし、そのような変更をしていないのであれば、ぜひ、変更してください。そうしないと、DRAW_NONEスタイルがサブウィンドウのグラフィックに影響し、全く別のスケールでなければならないことがわかりましたこれは修正されました。チケットを書いてから確認すると・・・。追記:2枚まであったことが判明しました。MT4では修正されましたが、MT5では修正されていないようです。 削除済み 2017.08.21 10:34 #19678 Stanislav Korotky:これは修正されました。チケットを書いてから確認しました。 それが、直ったかと思いきや、今度は直ってない。今確認しました。作品番号1643 Stanislav Korotky 2017.08.21 10:36 #19679 Alexey Kozitsyn: ここで、直ったと思ったのに、直ってない。今確認しました。作品番号1643上記参照、終了しました ;-) 削除済み 2017.08.21 10:36 #19680 Stanislav Korotky:上記参照、終了しました ;-) そうなんだ......。で、別のアプリケーションを作ります。 1...196119621963196419651966196719681969197019711972197319741975...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
ヘッダファイルに書くと「#import宣言がありません」というくだらない無駄な警告が出るのはなぜ?
まともなところでは、申告の回数に制限はない。mqhヘッダに利用可能な機能を簡単に記述したい場合、行をコメントしなければならず、可読性に悪影響が出るので困る。静的メソッドは クラスか構造体に入れろ(構造体を使うと「構造体にはメンバがありません、サイズは1バイトに割り当てられています」という素晴らしい警告が出ます)」という人もいるかもしれません。私は、このようなグーピーの警告の洪水なしに、「私はμlクラスが好きではありません、最初のオプションを使いたいのです」と答えます。なぜ、完全に有効な常識を放棄することを強要するのですか?
ヘッダーファイルに書くと「#import宣言がありません」という警告が出るのに、なぜこのような愚かで無駄なことをするのでしょうか。
これは特殊なケースです。より一般的なソリューションとして、アナログを追加することは理にかなっています。
#pragma warning (disable:xxxx)
で、経験豊富なプログラマーなら誰でも、この煩わしい警告を無効にすることができます(その番号はコマンドコンパイラで確認できます)。既存の警告システムは基本的に役に立たない...。プログラマーの書き方や経験を考慮していない同じようなものが何百とあるので、目も通しません。そして、これらの何百もの警告の中から、注意を払うに値する本当に重要な警告を見つけるのは難しい。これは特殊なケースです。より一般的なソリューションとして、アナログを追加することは理にかなっています。
そして、経験豊富なプログラマーなら誰でも、煩わしい警告を無効にすることができます(その数は、コマンドコンパイラで確認できます)。既存の警告システムは基本的に役に立たない...。プログラマーの書き方や経験を考慮していない同じような警告が何百とあるので、目を通すこともありません。そして、その何百もの中から、注意を払うに値する本当に重要なものを見つけるのは難しい。開発者の皆様へインジケータの計算が サブウィンドウにあり、そのバッファのいくつかのスタイルがDRAW_NONEである場合、それらはサブウィンドウの表示スケールに影響を与えないという事実について、編集があったことを思い出してください。それとも、そのような編集はなかったのでしょうか?
もし、そのような変更をしていないのであれば、ぜひ、変更してください。なぜなら、DRAW_NONEスタイルがサブウィンドウのグラフィックに影響し、全く異なるスケールであるべきだということがわかったからです
はい、そうですね。ただ、私は警告のセットを一度に管理する方が良いと思います。キーメカニズム(-Wno_allなど)または#pragma警告(レベル:{0|1|2|...})を使用します。1つずつ無効化するのは面倒だ。
おそらく何年も前から、警告やエラーのたびに、なぜそれが出てくるのかが明確にわかるような例を求めてきたのでしょう。
このように考えると、階層化やワラントの明示的な管理は幻想のように見えてきます。
開発者の皆様へインジケータの計算が サブウィンドウにあり、そのバッファのいくつかのスタイルがDRAW_NONEである場合、それらはサブウィンドウの表示スケールに影響を与えないという事実について編集されていたことを思い出してください。それとも、そのような編集はなかったのでしょうか?
もし、そのような変更をしていないのであれば、ぜひ、変更してください。そうしないと、DRAW_NONEスタイルがサブウィンドウのグラフィックに影響し、全く別のスケールでなければならないことがわかりました
これは修正されました。チケットを書いてから確認すると・・・。
追記:2枚まであったことが判明しました。MT4では修正されましたが、MT5では修正されていないようです。
これは修正されました。チケットを書いてから確認しました。
ここで、直ったと思ったのに、直ってない。今確認しました。作品番号1643
上記参照、終了しました ;-)
上記参照、終了しました ;-)