MQL5におけるOOPに関する質問 - ページ 47 1...404142434445464748495051525354...96 新しいコメント Alexey Navoykov 2020.04.21 12:31 #461 Igor Makanu:MTの開発者はいつも、コンパイラ内蔵のメカニズムを使えば、通常の関数さえも呼び出すよりも高速になると書いています。もし時間と興味があれば、私のバージョンとあなたのバージョンの速度をArrayCopyでチェックしてみてください。今、PCのレッスンで忙しいので、もう少ししてから速度を確認します。ArrayCopyを 勘違いしていました、配列の配列を持っているので、コピーされません。要素ごとにコピーする必要があるので、そう、あなたのやり方が最適なのです。 Igor Makanu 2020.04.21 12:40 #462 Alexey Navoykov: ArrayCopyについてはやりすぎましたね、配列の配列を持っていてもコピーされないんです。だから、あなたのやり方がいいんです。 ふぅ...。とりあえず一件落着 )))) MQLはC言語ライクという意見がありますが、PlusよりもSharpに近いというのがイミフです。 ほぼ99%のコードをMQLでコピーしました。 5-10分の作業です。 ZS: やりたいんですけど、このコード、ノートPCに入ってたと思うんですけど...覚えてないんですよ、探さないといけないし、家だと計算能力もないし...。全体的にごちゃごちゃしてますね ))) Vladimir Simakov 2020.04.21 12:54 #463 Igor Makanu: ふぅ...。とりあえず一件落着 )))) MQLはC言語ライクという意見がありますが、PlusよりもSharpに 近いというのがイミフです。 ほぼ99%のコードをMQLでコピーしました。 5-10分の作業です。 ZS: やりたいんですけど、このコードがノートPCにあったと思うんですけど...覚えてないので探さないといけないし、家だと計算能力がないので...。全体的にごちゃごちゃしてますね ))) プロから月ほど、シャープから冥王星の軌道ほど離れているのです。一般的な印象としては、すべてWinApiのイメージでやっています。 そう、プラスアルファがやはり基本なんです。 Igor Makanu 2020.04.21 13:09 #464 Vladimir Simakov: プラスは月と同じくらい近いし、シャープは冥王星の軌道と同じくらい近いんです。総じて、WinApiのイメージですべてを行っている印象です。 そう、プラスアルファがやはり基本です。 議論は尽きませんが、STLの移植問題はもう解決したんでしょう? 議論のスピードを上げるために...。STLやポインタの扱いを取り除いてしまうと、MQLの機能を出力することはできません。 しかし、同じようにC#に "take away mine "を適用すると、Sharpに残されたものはMQLのような可能性を持つかもしれません。 ;) Vladimir Simakov 2020.04.21 13:29 #465 Igor Makanu: 議論は尽きませんが、STLの移植問題はもう解決したんでしょう? 議論のスピードを上げるために...。STLやポインタの扱いを取り除いてしまうと、MQLの機能を出力することはできません。 しかし、同じようにC#に "take away mine "を適用すると、Sharpに残されたものはMQLのような可能性を持つかもしれません。 ;) Cからポインタを取り除けばCもなくなるし、stlは単なるライブラリに過ぎないのに))) また、シャープから何を取り出そうというのでしょうか、オブジェ?)同じような効果が期待できます。 ちなみに、mqlのテンプレートは、C#からのジェネリックではなく、Cからのテンプレートのままです(コンパイル時)。また、Sharpにはマクロはありません)。 Sergey Dzyublik 2020.04.21 13:41 #466 Vladimir Simakov: Cからポインターを取り除けば、Cは存在しなくなり、stlは単なるライブラリになります)。 そして、シャープから何を取り除けというのでしょうか、オブジェクトを)同じような効果が期待できます。 ちなみに、mqlのテンプレートは、C#からのジェネリックではなく、Cからのテンプレートのままです(コンパイル時)。また、シャープにはマクロはありません)。 イゴール・マカヌと 議論するのは、時間と労力の無駄だと思う。 この人は、研修生レベルの些細な問題を 理解せずに、上級の事柄を論じようとしているのです。 Alexey Navoykov 2020.04.21 13:42 #467 Igor Makanu: 議論は尽きませんが、STLの移植問題はもう解決したんでしょう? 議論のスピードを上げるために...。STLやポインタの扱いを取り除いてしまうと、MQLの機能を出力することはできません。 でも、C#に同じように "Take away mine "を適用したら、シャープの残骸はMQLのようになるかもしれない? ;) STLは単なるライブラリです。使っても使わなくても言語の可能 性に影響はなく、従来通りMQLより2頭身高くなります。 また、Sharpは配列の部分だけMQLに似ています。 残りの部分については、MQLは99年以前のC++を思い起こさせます。 Igor Makanu 2020.04.21 13:51 #468 Sergey Dzyublik: イゴール・マカヌと 議論する時間とエネルギーを浪費する必要はないと思うんだ。研修生レベルの些細な疑問も 理解せず、高度な議論をしようとしている人がいる。 議論しないでください、あなたの時間を無駄にしないでください、それは私がセルゲイDzyublikに 書いたようなものではありません - 返信する;) トピックのタイトルをご覧になりましたか?- 私の質問は、このスレッドに対応していますか?- まあ、今日は誰もあなたのエゴを満足させるという仕事を私に課してはいないのですが)))) ウラジミール・シマコフ Cからポインタを取ったらCは全く使えなくなるし、stlは単なるライブラリに過ぎないのに))) それはわかるのですが、高級言語というのは出来合いのソリューションがあって面白いのであって、そうでなければ今頃は半日もprintf()を書くのに精一杯でしょう))) アレクセイ・ナヴォイコフ また、Sharpは配列の部分だけMQLに似ています。 残りの部分については、MQLは99年以前のC++を思い起こさせます。 あなたの言うことは正しいかもしれません。 Sergey Dzyublik 2020.04.21 14:14 #469 Igor Makanu: 議論すべきことはたくさんありますが、すでにSTLの移植で問題に遭遇していますよね? std::vectorをC++からMQLに移植する際に遭遇した主な問題点です。 1)バグ(ここも全てではない)。 2) 標準関数が特定のデータ型に対してのみ適切に動作する (最大速度を得るために、型に応じて条件付きコンパイルをサポートした普遍的な ArrayCopy, ArrayFill を手動で記述する必要がある)。 3) 標準的な関数は、特定のデータ型に対して十分にゆっくりと動作します(単純なデータ型に対して、素早くResize+ReserveするためにArrayResizeを手動で規定する必要があります)。 4)そして、4位のみ機能性の欠如-「typedef宣言」の欠如(#define、クラスや構造体の継承、単純な型のためのラッパークラスの使用によって回避される)。 Alexey Navoykov 2020.04.21 14:24 #470 MQLがどんな言語であるかは、実はあまり重要ではなく、C++よりも高レベルで、そのコードはよりシンプルで簡潔であるべきだとされています。 しかし実際はその逆で、MQLのコードはずっと面倒で不器用です。 多くのものを一緒に握りしめなければならないのです。 1...404142434445464748495051525354...96 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
MTの開発者はいつも、コンパイラ内蔵のメカニズムを使えば、通常の関数さえも呼び出すよりも高速になると書いています。
もし時間と興味があれば、私のバージョンとあなたのバージョンの速度をArrayCopyでチェックしてみてください。
今、PCのレッスンで忙しいので、もう少ししてから速度を確認します。
ArrayCopyについてはやりすぎましたね、配列の配列を持っていてもコピーされないんです。だから、あなたのやり方がいいんです。
ふぅ...。とりあえず一件落着 ))))
MQLはC言語ライクという意見がありますが、PlusよりもSharpに近いというのがイミフです。
ほぼ99%のコードをMQLでコピーしました。 5-10分の作業です。
ZS: やりたいんですけど、このコード、ノートPCに入ってたと思うんですけど...覚えてないんですよ、探さないといけないし、家だと計算能力もないし...。全体的にごちゃごちゃしてますね )))
ふぅ...。とりあえず一件落着 ))))
MQLはC言語ライクという意見がありますが、PlusよりもSharpに 近いというのがイミフです。
ほぼ99%のコードをMQLでコピーしました。 5-10分の作業です。
ZS: やりたいんですけど、このコードがノートPCにあったと思うんですけど...覚えてないので探さないといけないし、家だと計算能力がないので...。全体的にごちゃごちゃしてますね )))
プロから月ほど、シャープから冥王星の軌道ほど離れているのです。一般的な印象としては、すべてWinApiのイメージでやっています。 そう、プラスアルファがやはり基本なんです。
プラスは月と同じくらい近いし、シャープは冥王星の軌道と同じくらい近いんです。総じて、WinApiのイメージですべてを行っている印象です。 そう、プラスアルファがやはり基本です。
議論は尽きませんが、STLの移植問題はもう解決したんでしょう?
議論のスピードを上げるために...。STLやポインタの扱いを取り除いてしまうと、MQLの機能を出力することはできません。
しかし、同じようにC#に "take away mine "を適用すると、Sharpに残されたものはMQLのような可能性を持つかもしれません。
;)
議論は尽きませんが、STLの移植問題はもう解決したんでしょう?
議論のスピードを上げるために...。STLやポインタの扱いを取り除いてしまうと、MQLの機能を出力することはできません。
しかし、同じようにC#に "take away mine "を適用すると、Sharpに残されたものはMQLのような可能性を持つかもしれません。
;)
Cからポインタを取り除けばCもなくなるし、stlは単なるライブラリに過ぎないのに)))
また、シャープから何を取り出そうというのでしょうか、オブジェ?)同じような効果が期待できます。
ちなみに、mqlのテンプレートは、C#からのジェネリックではなく、Cからのテンプレートのままです(コンパイル時)。また、Sharpにはマクロはありません)。
Cからポインターを取り除けば、Cは存在しなくなり、stlは単なるライブラリになります)。
そして、シャープから何を取り除けというのでしょうか、オブジェクトを)同じような効果が期待できます。
ちなみに、mqlのテンプレートは、C#からのジェネリックではなく、Cからのテンプレートのままです(コンパイル時)。また、シャープにはマクロはありません)。
イゴール・マカヌと 議論するのは、時間と労力の無駄だと思う。
この人は、研修生レベルの些細な問題を 理解せずに、上級の事柄を論じようとしているのです。
議論は尽きませんが、STLの移植問題はもう解決したんでしょう?
議論のスピードを上げるために...。STLやポインタの扱いを取り除いてしまうと、MQLの機能を出力することはできません。
でも、C#に同じように "Take away mine "を適用したら、シャープの残骸はMQLのようになるかもしれない?
;)
STLは単なるライブラリです。使っても使わなくても言語の可能 性に影響はなく、従来通りMQLより2頭身高くなります。
また、Sharpは配列の部分だけMQLに似ています。 残りの部分については、MQLは99年以前のC++を思い起こさせます。
イゴール・マカヌと 議論する時間とエネルギーを浪費する必要はないと思うんだ。
研修生レベルの些細な疑問も 理解せず、高度な議論をしようとしている人がいる。
議論しないでください、あなたの時間を無駄にしないでください、それは私がセルゲイDzyublikに 書いたようなものではありません - 返信する;)
トピックのタイトルをご覧になりましたか?- 私の質問は、このスレッドに対応していますか?- まあ、今日は誰もあなたのエゴを満足させるという仕事を私に課してはいないのですが))))
Cからポインタを取ったらCは全く使えなくなるし、stlは単なるライブラリに過ぎないのに)))
それはわかるのですが、高級言語というのは出来合いのソリューションがあって面白いのであって、そうでなければ今頃は半日もprintf()を書くのに精一杯でしょう)))
また、Sharpは配列の部分だけMQLに似ています。 残りの部分については、MQLは99年以前のC++を思い起こさせます。
あなたの言うことは正しいかもしれません。
議論すべきことはたくさんありますが、すでにSTLの移植で問題に遭遇していますよね?
std::vectorをC++からMQLに移植する際に遭遇した主な問題点です。
1)バグ(ここも全てではない)。
2) 標準関数が特定のデータ型に対してのみ適切に動作する (最大速度を得るために、型に応じて条件付きコンパイルをサポートした普遍的な ArrayCopy, ArrayFill を手動で記述する必要がある)。
3) 標準的な関数は、特定のデータ型に対して十分にゆっくりと動作します(単純なデータ型に対して、素早くResize+ReserveするためにArrayResizeを手動で規定する必要があります)。
4)そして、4位のみ機能性の欠如-「typedef宣言」の欠如(#define、クラスや構造体の継承、単純な型のためのラッパークラスの使用によって回避される)。