学童のためのEOPです。 - ページ 6 12345678910111213...18 新しいコメント Dmitry Fedoseev 2019.10.04 11:58 #51 Ihor Herasko: OKです。ゲッターの定義を教えてください。 は馬ではない Ihor Herasko 2019.10.04 12:10 #52 Dmitry Fedoseev: は馬ではありません。 私は、自分が知っていることを説明できる人が相手だと思っていました。しかし、ここで、定義のレベルでもトラブルが発生します。 Dmitry Fedoseev 2019.10.04 12:16 #53 Ihor Herasko: 自分の知っていることを説明できる人が相手だと思ったからです。私は、自分が知っていることを説明できる人が相手だと思っていました。 そうだ、好きなように空想してくれ、私はとっくにすべてを理解している、ここにいる何人かも、祖母の腹いせに耳を凍らせる用意をしているのだ。 Ihor Herasko 2019.10.04 12:19 #54 Dmitry Fedoseev: 好きなだけ妄想してください、私もここにいる何人かの方とは長い間、全てを理解してきました。 すべてがクリアになる。説明できないだけです)) Dmitry Fedoseev 2019.10.04 12:20 #55 Ihor Herasko: すべてがクリアになる。説明できないだけだろう) おばあちゃんを困らせるために、耳を凍らせ続けてください。 Igor Makanu 2019.10.04 12:22 #56 Alexey Viktorov: 作成した最初の1分からずっと読んでいます。 タスクを設定して手続き型で書き、それを（難しくはないが）OOP型で書き直すということをやってみる必要がある。 TCが繰り返し書いているように、OOPはタスクを素早くスケールアップし、開発をスピードアップさせ、プログラムを書く際のミスを減らすことを可能にします MQLの場合：私が最も苦手とする問題のひとつに、一連の注文の部分決済があります。手続き型プログラミングのスタイルでは、ひとつの注文を決済するサブプログラムを呼び出した後、エラー処理を整理する必要があります。一度の呼び出しですべての注文を部分決済できなかった場合はどうすればいいのでしょうか？- サーバーが部分的に閉じることを許可しなかったのですか？- 私は今年の初めにこの質問をした、よく、いつものように、ケースの99％で、すべての一般的な解決策は、注文のコメントの分析に減少した - そこに読んで、サーバーがそこにすべてを書き込むように...イモ、プロではない OOPスタイルでは、この問題は「2クリックで」解決します。注文を部分的に閉じるメソッドを呼び出し、注文の状態に関する データ（チケット、その変更の必要性...）と注文を扱うメソッドをORDERクラスに格納することで、次の作業に対して最大の柔軟性と拡張性を持つソリューションになります、私の意見では MQLでグラフィックを扱う場合も同様で、テキストラベルが1枚なら問題ありませんが、10～100枚のラベルがある場合はどうでしょうか。- あるラベルは "コーラル "色、あるラベルは "ボタン付きパール "といったように、選択的に配色を変える必要がある場合は？ ...そして1週間後、さらに3つのボタンを追加するのにかかった..........。そして1週間後、さらに10個のボタンを取り外す必要がありました......。 ZS：また風車合戦の話題か・・・。いや、ある人を思い出した（名字を忘れた））。)- 地球は丸いと言って炎上したのは誰だっけ？))))- 無教養の克服、心の豊かさとは、こういうことだ。 Alexey Viktorov 2019.10.04 14:01 #57 Igor Makanu: タスクを設定して手続き型で書き、それを（難しくはないが）OOP型で書き直すということをやってみる必要がある。 TCが繰り返し書いているように、OOPはタスクを素早くスケールアップし、開発をスピードアップさせ、プログラムを書く際のミスを減らすことを可能にします MQLの場合：私が最も苦手とする問題のひとつに、一連の注文の部分決済があります。手続き型プログラミングのスタイルでは、ひとつの注文を決済するサブプログラムを呼び出した後、エラー処理を整理する必要があります。一度の呼び出しですべての注文を部分決済できなかった場合はどうすればいいのか？- サーバーが部分的に閉じることを許可しなかったのですか？- 私は今年の初めにこの質問をした、よく、いつものように、ケースの99％で、すべての一般的な解決策は、注文のコメントの分析に減少した - そこに読んで、サーバーがそこにすべてを書き込むように...イモ、プロではない OOPスタイルでは、この問題は「2クリックで」解決します。注文を部分的に閉じるメソッドを呼び出し、注文の状態に関する データ（チケット、その変更の必要性...）と注文を扱うメソッドをORDERクラスに格納することで、次の作業に対して最大の柔軟性と拡張性を持つソリューションになります、私の意見では MQLでグラフィックを扱う場合も同様で、テキストラベルが1枚なら問題ありませんが、10～100枚のラベルがある場合はどうでしょうか。- あるラベルは "コーラル "色、あるラベルは "ボタン付きパール "といったように、選択的に配色を変える必要がある場合は？ ...そして1週間後、さらに3つのボタンを追加するのにかかった...というわけです。そして1週間後、さらに10個のボタンを取り外す必要がありました......。 ZS：また風車合戦の話題か・・・。いや、ある人を思い出した（名字を忘れた））。)- 地球は丸いと言って炎上したのは誰だっけ？))))- これこそ、無教養と戦う、視野を広げるということです。 私見ですが、mqlでは、OOPで解決すべき問題は非常に狭いと思います。言語そのものは、C++とかでOOPしているに過ぎないような気がします。そしてこのOOPは、標準ライブラリという形で提供されています。そして、このOOPに、そうでなければ言わないが、別のOOPを追加することが提案されている。 そして、もう一歩...。正しくウォーロックは、怒っているが、慈悲深い、私のタスクのために、OOPは犬のターンテーブルのようなものです。また、問題を設定し、それをOOPで実装しても、その問題が手続き型で問題なく解決できるのであれば、何の意味があるのでしょうか。 例えば、fxsaber`aから.mqhを取り出し、MT4だけでなくMT5用のコードも記述することができます。たぶん、誰かが必要としているのでしょう。でも、誰だか見てください...mql5を使いたくない人、どうしても使いこなせない人。あるいは、ニコライ・・・彼の名字は忘れましたが、iCanvas を使ってください。便利なライブラリのようですが、わかりにくいし、ちょっとした説明書すらありません。文句じゃなくて、ごめんね、ニコライ、事実なんだ。 だから、グラフィカルなラベルを書いてみようと思ったとき、標準ライブラリもニコライのライブラリも参照しない方が書きやすかったんです。 Igor Makanu 2019.10.04 14:16 #58 Alexey Viktorov: 私見ですが、mqlはOOPで解決すべきタスクが非常に狭いと思います。この言語自体は、C++か何かのOOPに過ぎないように思います。そしてこのOOPは、標準ライブラリという形で提供されています。そして、このOOPに、言い換えれば、別のOOPを挿入することが提案されている。そして、もう一歩...。正しくウォーロックは、怒っているが、慈悲深い、私のタスクのために、OOPは犬のターンテーブルのようなものです。また、問題を設定し、それをOOPで実装しても、その問題が手続き型で問題なく解決できるのであれば、何の意味があるのでしょう。 残念ながら90％は正しいのですが、ただ、トレーダーが書くように依頼するトレーディングストラテジーは．正直言って原始的です。 MQLで質の高いグラフィックパネルが作れるようになった時は盛り上がりましたが、エンドユーザーも必要としていないことが判明しました。これは業界の問題で、一般の人はモッタイナイですが、興味を持っているのです．彼らが欲しいのは1つのボタン、お金だけです． アレクセイ・ヴィクトロフ 例えば、fxsaber`aの.mqhを利用して、MT4だけでなくMT5用のコードも記述することができます。たぶん、誰かが必要としているのだろうけど、でも、誰を見て・・・。mql5を使いたくない人、絶対に使いこなせない人。 mt5が必要なので、このライブラリを使っているのですが、オーダーシステムの勉強に時間をかけたくないので、MT5初心者スレッドで1、2回聞いてみたのですが・・・。オーダーシステムの勉強に時間を割きたくないのですが、MT5初心者ブランチで何度か試してみたのですが、結果はダメでした。実際、オーダーシステムの仕組みを知っていて、私の質問に答えてくれる人はそこにはいないのです...。まあ、控えめに言って「ごちゃごちゃ」なんですけどね。 アレクセイ・ヴィクトロフ あるいは、ニコライのiCanvasを......彼の名字は忘れました、わかりますよね？便利なライブラリのようだが、理解するのは容易ではなく、わずかな説明文さえもない。文句じゃなくて、ごめんね、ニコライさん、事実なんだ。だから、グラフィカルなラベルを書いてみようと思ったとき、標準ライブラリもニコライのライブラリも参照しない方が書きやすかったんです。 ニコライ・セムコ（@Nikolai Semko）氏の ライブラリを何度か使用したことがあります。KBで毎日リリースされるEAの99％がそうであるように、モデレーターは注文システムを気にしないのでしょうか？- AdSはOOPの形で書かれており、彼が考えたどんなEAでも作り出すことができる。 Реter Konow 2019.10.04 14:27 #59 Alexey Viktorov: 私見ですが、mqlはOOPで解決すべきタスクが非常に狭いと思います。この言語自体は、C++か何かのOOPに過ぎないように思います。そしてこのOOPは、標準ライブラリという形で提供されています。そして、このOOPに、そうでなければ言わないが、別のOOPを追加することが提案されている。そして、もう一歩...。正しくウォーロックは、怒っているが、慈悲深い、私のタスクのために、OOPは犬のターンテーブルのようなものです。また、問題を設定し、それをOOPで実装しても、その問題が手続き型で問題なく解決できるのであれば、何の意味があるのでしょう。 例えば、fxsaberから.mqhを取り出し、MT5用のコードをMT4用として記述します。多分、誰かが必要としているのだろうが、誰を見ている。mql5を使いたくない人、絶対に使いこなせない人へ。あるいは、ニコライ・・・彼の名字は忘れましたが、iCanvas を使ってください。便利なライブラリのようですが、わかりにくいし、ちょっとした説明書すらありません。文句じゃなくて、ごめんね、ニコライ、事実なんだ。だから、グラフィカルなラベルを書いてみようと思ったとき、標準ライブラリもニコライのライブラリも参照しない方が書きやすかったんです。 OOPの適用には、アルゴリズム取引よりもはるかに高いレベルの複雑なタスクが必要です。だから紛争が起こるのです。OOPは、プロのプログラマーや開発者が複雑なプログラムに対応するために必要なものです。そのような真剣勝負をする余地はほとんどありません。 小さな例でOOPの意味を説明するのは間違っています。OOPの意義は、膨大な量のデータや関数を扱う大規模な作業にあります。データの多様性には分離と分類が必要であり、さらに記述のカプセル化、階層的に分離されたクラス間でのプロパティやメソッドの継承などの関連性がある。 これでは、小さなタスクでは意味がありません。 Реter Konow 2019.10.04 14:38 #60 プログラマーはOOPを学ぶと、すぐに大規模なプログラムの世界に入り、そこでナビゲーションを始める。しかし、この「世界」での自分の役割は小さいかもしれない。そんなことはどうでもいいのです。プログラムや図書館という共通の海に入り、そこで何をするのかが決まっているだけなのです。アルゴトレーダーは必要ですか？何とも言えませんね。必要な人はそれを使いこなす。あとは、じっくり考えて何かに挑戦して、それをOOPと呼ぶ...。 12345678910111213...18 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
OKです。ゲッターの定義を教えてください。
は馬ではない
は馬ではありません。
私は、自分が知っていることを説明できる人が相手だと思っていました。しかし、ここで、定義のレベルでもトラブルが発生します。
自分の知っていることを説明できる人が相手だと思ったからです。私は、自分が知っていることを説明できる人が相手だと思っていました。
そうだ、好きなように空想してくれ、私はとっくにすべてを理解している、ここにいる何人かも、祖母の腹いせに耳を凍らせる用意をしているのだ。
好きなだけ妄想してください、私もここにいる何人かの方とは長い間、全てを理解してきました。
すべてがクリアになる。説明できないだけです))
すべてがクリアになる。説明できないだけだろう)
おばあちゃんを困らせるために、耳を凍らせ続けてください。
作成した最初の1分からずっと読んでいます。
タスクを設定して手続き型で書き、それを（難しくはないが）OOP型で書き直すということをやってみる必要がある。
TCが繰り返し書いているように、OOPはタスクを素早くスケールアップし、開発をスピードアップさせ、プログラムを書く際のミスを減らすことを可能にします
MQLの場合：私が最も苦手とする問題のひとつに、一連の注文の部分決済があります。手続き型プログラミングのスタイルでは、ひとつの注文を決済するサブプログラムを呼び出した後、エラー処理を整理する必要があります。一度の呼び出しですべての注文を部分決済できなかった場合はどうすればいいのでしょうか？- サーバーが部分的に閉じることを許可しなかったのですか？- 私は今年の初めにこの質問をした、よく、いつものように、ケースの99％で、すべての一般的な解決策は、注文のコメントの分析に減少した - そこに読んで、サーバーがそこにすべてを書き込むように...イモ、プロではない
OOPスタイルでは、この問題は「2クリックで」解決します。注文を部分的に閉じるメソッドを呼び出し、注文の状態に関する データ（チケット、その変更の必要性...）と注文を扱うメソッドをORDERクラスに格納することで、次の作業に対して最大の柔軟性と拡張性を持つソリューションになります、私の意見では
MQLでグラフィックを扱う場合も同様で、テキストラベルが1枚なら問題ありませんが、10～100枚のラベルがある場合はどうでしょうか。- あるラベルは "コーラル "色、あるラベルは "ボタン付きパール "といったように、選択的に配色を変える必要がある場合は？ ...そして1週間後、さらに3つのボタンを追加するのにかかった..........。そして1週間後、さらに10個のボタンを取り外す必要がありました......。
ZS：また風車合戦の話題か・・・。いや、ある人を思い出した（名字を忘れた））。)- 地球は丸いと言って炎上したのは誰だっけ？))))- 無教養の克服、心の豊かさとは、こういうことだ。
タスクを設定して手続き型で書き、それを（難しくはないが）OOP型で書き直すということをやってみる必要がある。
TCが繰り返し書いているように、OOPはタスクを素早くスケールアップし、開発をスピードアップさせ、プログラムを書く際のミスを減らすことを可能にします
MQLの場合：私が最も苦手とする問題のひとつに、一連の注文の部分決済があります。手続き型プログラミングのスタイルでは、ひとつの注文を決済するサブプログラムを呼び出した後、エラー処理を整理する必要があります。一度の呼び出しですべての注文を部分決済できなかった場合はどうすればいいのか？- サーバーが部分的に閉じることを許可しなかったのですか？- 私は今年の初めにこの質問をした、よく、いつものように、ケースの99％で、すべての一般的な解決策は、注文のコメントの分析に減少した - そこに読んで、サーバーがそこにすべてを書き込むように...イモ、プロではない
OOPスタイルでは、この問題は「2クリックで」解決します。注文を部分的に閉じるメソッドを呼び出し、注文の状態に関する データ（チケット、その変更の必要性...）と注文を扱うメソッドをORDERクラスに格納することで、次の作業に対して最大の柔軟性と拡張性を持つソリューションになります、私の意見では
MQLでグラフィックを扱う場合も同様で、テキストラベルが1枚なら問題ありませんが、10～100枚のラベルがある場合はどうでしょうか。- あるラベルは "コーラル "色、あるラベルは "ボタン付きパール "といったように、選択的に配色を変える必要がある場合は？ ...そして1週間後、さらに3つのボタンを追加するのにかかった...というわけです。そして1週間後、さらに10個のボタンを取り外す必要がありました......。
ZS：また風車合戦の話題か・・・。いや、ある人を思い出した（名字を忘れた））。)- 地球は丸いと言って炎上したのは誰だっけ？))))- これこそ、無教養と戦う、視野を広げるということです。
私見ですが、mqlでは、OOPで解決すべき問題は非常に狭いと思います。言語そのものは、C++とかでOOPしているに過ぎないような気がします。そしてこのOOPは、標準ライブラリという形で提供されています。そして、このOOPに、そうでなければ言わないが、別のOOPを追加することが提案されている。 そして、もう一歩...。正しくウォーロックは、怒っているが、慈悲深い、私のタスクのために、OOPは犬のターンテーブルのようなものです。また、問題を設定し、それをOOPで実装しても、その問題が手続き型で問題なく解決できるのであれば、何の意味があるのでしょうか。
例えば、fxsaber`aから.mqhを取り出し、MT4だけでなくMT5用のコードも記述することができます。たぶん、誰かが必要としているのでしょう。でも、誰だか見てください...mql5を使いたくない人、どうしても使いこなせない人。あるいは、ニコライ・・・彼の名字は忘れましたが、iCanvas を使ってください。便利なライブラリのようですが、わかりにくいし、ちょっとした説明書すらありません。文句じゃなくて、ごめんね、ニコライ、事実なんだ。 だから、グラフィカルなラベルを書いてみようと思ったとき、標準ライブラリもニコライのライブラリも参照しない方が書きやすかったんです。
私見ですが、mqlはOOPで解決すべきタスクが非常に狭いと思います。この言語自体は、C++か何かのOOPに過ぎないように思います。そしてこのOOPは、標準ライブラリという形で提供されています。そして、このOOPに、言い換えれば、別のOOPを挿入することが提案されている。そして、もう一歩...。正しくウォーロックは、怒っているが、慈悲深い、私のタスクのために、OOPは犬のターンテーブルのようなものです。また、問題を設定し、それをOOPで実装しても、その問題が手続き型で問題なく解決できるのであれば、何の意味があるのでしょう。
残念ながら90％は正しいのですが、ただ、トレーダーが書くように依頼するトレーディングストラテジーは．正直言って原始的です。 MQLで質の高いグラフィックパネルが作れるようになった時は盛り上がりましたが、エンドユーザーも必要としていないことが判明しました。これは業界の問題で、一般の人はモッタイナイですが、興味を持っているのです．彼らが欲しいのは1つのボタン、お金だけです．
例えば、fxsaber`aの.mqhを利用して、MT4だけでなくMT5用のコードも記述することができます。たぶん、誰かが必要としているのだろうけど、でも、誰を見て・・・。mql5を使いたくない人、絶対に使いこなせない人。
mt5が必要なので、このライブラリを使っているのですが、オーダーシステムの勉強に時間をかけたくないので、MT5初心者スレッドで1、2回聞いてみたのですが・・・。オーダーシステムの勉強に時間を割きたくないのですが、MT5初心者ブランチで何度か試してみたのですが、結果はダメでした。実際、オーダーシステムの仕組みを知っていて、私の質問に答えてくれる人はそこにはいないのです...。まあ、控えめに言って「ごちゃごちゃ」なんですけどね。
あるいは、ニコライのiCanvasを......彼の名字は忘れました、わかりますよね？便利なライブラリのようだが、理解するのは容易ではなく、わずかな説明文さえもない。文句じゃなくて、ごめんね、ニコライさん、事実なんだ。だから、グラフィカルなラベルを書いてみようと思ったとき、標準ライブラリもニコライのライブラリも参照しない方が書きやすかったんです。
ニコライ・セムコ（@Nikolai Semko）氏の ライブラリを何度か使用したことがあります。KBで毎日リリースされるEAの99％がそうであるように、モデレーターは注文システムを気にしないのでしょうか？- AdSはOOPの形で書かれており、彼が考えたどんなEAでも作り出すことができる。
私見ですが、mqlはOOPで解決すべきタスクが非常に狭いと思います。この言語自体は、C++か何かのOOPに過ぎないように思います。そしてこのOOPは、標準ライブラリという形で提供されています。そして、このOOPに、そうでなければ言わないが、別のOOPを追加することが提案されている。そして、もう一歩...。正しくウォーロックは、怒っているが、慈悲深い、私のタスクのために、OOPは犬のターンテーブルのようなものです。また、問題を設定し、それをOOPで実装しても、その問題が手続き型で問題なく解決できるのであれば、何の意味があるのでしょう。
例えば、fxsaberから.mqhを取り出し、MT5用のコードをMT4用として記述します。多分、誰かが必要としているのだろうが、誰を見ている。mql5を使いたくない人、絶対に使いこなせない人へ。あるいは、ニコライ・・・彼の名字は忘れましたが、iCanvas を使ってください。便利なライブラリのようですが、わかりにくいし、ちょっとした説明書すらありません。文句じゃなくて、ごめんね、ニコライ、事実なんだ。だから、グラフィカルなラベルを書いてみようと思ったとき、標準ライブラリもニコライのライブラリも参照しない方が書きやすかったんです。
OOPの適用には、アルゴリズム取引よりもはるかに高いレベルの複雑なタスクが必要です。だから紛争が起こるのです。OOPは、プロのプログラマーや開発者が複雑なプログラムに対応するために必要なものです。そのような真剣勝負をする余地はほとんどありません。 小さな例でOOPの意味を説明するのは間違っています。OOPの意義は、膨大な量のデータや関数を扱う大規模な作業にあります。データの多様性には分離と分類が必要であり、さらに記述のカプセル化、階層的に分離されたクラス間でのプロパティやメソッドの継承などの関連性がある。
これでは、小さなタスクでは意味がありません。