ラウンジでPLOについて語る - ページ 7 1234567891011121314...23 新しいコメント TheXpert 2018.01.13 18:21 #61 Alexey Volchanskiy:ZS：ところで、スレッド全体では、いつもの揉め事で、どの話題も取材希望が一件もありませんでしたね。最初の例の選択からして、報道の質には相応の疑問がある Vasiliy Sokolov 2018.01.13 18:26 #62 Alexey Volchanskiy: 彼らが何者で、 何を学んで いないのか、もっと具体的に説明できないか。モデレーターは掃除の仕方など勉強していない )ZS：ところで、スレッド全体では、いつものように、どのトピックをカバーするために単一の願いを見なかった、いつものようにわだかまり。そこで、せめて何かの役に立てばと思い、OOPの仕組みを一からYouTubeで動画撮影することにしました。とにかく、しばらくするとブランチがbranch_suckerで終わってしまうのです。もっと正確に 言うと、彼らはOOPの使い方を学んでいないのです。アレクセイ、あなたはOOPを単純に学ぶことができないことを自分自身でよく理解していると思います。継承、カプセル化、ポリモーフィズムなど、OOPの正式な知識はよく繰り返されますが、誰かがそれらを暗記し、MMモジュールから継承するExpertクラスなど、暴力的かつ不適切に適用することによる害は、益々多くなります（SB開発者の皆さんこんにちは:)。MQLに関しては、OOPの観点からは非常に弱い言語 です。型制御は全くなく（少なくとも安全な変換はできました）、リフレクションは初期段階にあり非常に限定的で、インターフェースは全くありません。MQLでどのようなOOPを教えることができるのか、という疑問が生まれます。開発者自身がStandard Libraryを 滅茶苦茶にしているのだから、時には怖いくらいだとしたら、何と言えばいいのだろう。 Alexey Volchanskiy 2018.01.13 18:38 #63 Vasiliy Sokolov:もっと正確に言うと、 私たちはOOPを学んでいないのです。アレクセイ、あなたはOOPを学ぶだけではダメだということをよく分かっていると思います。継承、カプセル化、ポリモーフィズムなど、OOPの正式な知識はよく繰り返されますが、誰かがそれらを暗記し、MMモジュールから継承するExpertクラスなど、暴力的で不適切な適用による害の方が多いのです（SB開発者の皆さん、こんにちは：）。MQLに関しては、OOPの観点からは非常に弱い言語 です。型制御は全くなく（少なくとも安全な変換はできました）、リフレクションは初期段階にあり非常に限定的で、インターフェースは全くありません。MQLでどのようなOOPを教えることができるのか、という疑問が生まれます。開発者自身がStandard Libraryの ようなハンパなものを成形してしまうと、時には怖い思いをすることもあるので、何と言うか。確かに弱いですが、中程度の深刻さのプロジェクトならまだ可能です。SBは、さまざまな人がさまざまなレベルのトレーニングを受けています。そして、肝心なところが欠けています。私は今でも貴社のCDictionaryを使っていますが、マスト・デューのことです。さあ、どうする、横になって死ぬのか？))やっぱりDELLに入るかもしれません。OOPを学ぶことができるのではないでしょうか。自分で覚えたんです。そして、他の人もそうでした。 Vasiliy Sokolov 2018.01.13 18:52 #64 Alexey Volchanskiy:そして、まだOOPを学ぶことができると思います。自分で覚えたんです。そして、それは他の人たちも同じです。だから、正しい事例から学ぶ必要があるのです。でも、SBにはないんです。CObjectは型の制御を提供せず、オブジェクトとのインターフェースレベルの作業も提供せず、Save()やLoad()のような実際には再定義されることのない無意味なメソッドを含んでいるのです。m_prev と m_next ポインタは、単一のCList クラスで 使用されますが、その子孫のすべてのクラスでバラストとして存在します。最も便利なのはComparer()メソッドです。実際には最も頻繁に上書きされます。しかし、良い意味でComparer()はインターフェースであり、CObjectの中に定義するのではなく、別のクラスとして定義する必要があります。 Maxim Dmitrievsky 2018.01.13 18:53 #65 fxsaber:どうやらstaticとconst（これはOOPではない）は必要ないようです。OOPに関しては、実用性の高い（抽象的でない）次の関数が手続き型になるとどうなるのか、非常に興味深いですね。もちろん、どんなOOPも手続き型に書き換えることは可能です。でも、練習には興味があります。そこで、OOPも最低限使われている上記のような小さなコードをとってみました。では、この例で、手続き型はOOPと比較して、どれだけすっきりしているか／便利か／読みやすいか／正しいか？さて、数ページにわたって話をするわけではありませんが、短いソースコードの手続き型とOOPを比較するだけです。OOPの対戦相手には、名人芸を見せてもらう。これは、恐るべきMT5ではなく、古き良きMT4です。同じようにプログラミングを学ぶにはどうしたらいいのでしょうか？:) とてもいい感じです。あるいは、考え方を変える必要があるのかもしれません。例えば、構造体がクラスとほぼ同じようにコンストラクタで使用できることは知りませんでした。 TheXpert 2018.01.13 19:00 #66 Maxim Dmitrievsky:例えば、構造体がクラスとほぼ同じようにコンストラクタで使用できることを知りませんでした。 C++では、クラスと構造体は同じで、いくつかのデフォルトが異なるだけです。 Vasiliy Sokolov 2018.01.13 19:01 #67 Maxim Dmitrievsky: 全く同じようにプログラミングを学べる金型は？とてもいい感じです。とか、自分の意識も変える必要があるのかもしれません。例えば、構造体がコンストラクタでほとんどクラスのように使用できることは知りませんでした。また、fxsaberのコードのどこが天才的なのか、お聞かせください。IsChangeの副作用に魅了されたのかもしれませんし、システムの状態をユーザーレベルで複製しなければならないという考えなのかもしれません。 Maxim Dmitrievsky 2018.01.13 19:04 #68 Vasiliy Sokolov:fxsaberのコードのどこが天才的なのか、お聞かせください。IsChangeの副作用に魅了されたのか、それともシステムの状態をユーザーレベルで複製すべきだという考えなのか？おそらく、私はこのコードをほとんど理解していないためです :)すみません、私はプログラマーとしては素人なので...OOPは基本的なレベルしか知らないのですが...。 Maxim Dmitrievsky 2018.01.13 19:05 #69 Комбинатор: C++では、クラスと構造体は同じで、いくつかのデフォルトが異なるだけです。かっこいい！知らなかった...もっとプロを勉強しないといけないのかな。 Yuriy Asaulenko 2018.01.13 19:40 #70 Vasiliy Sokolov:だから、正しい事例から学ぶ必要があるのです。しかもSBにはない。CObjectを例にとると、型制御を提供せず、オブジェクトとのインターフェースレベルの作業も提供せず、Save()やLoad()のような実際には決してオーバーライドされない無意味なメソッドを含んでいるのです。m_prev と m_next ポインタは、単一のCList クラスで 使用されますが、その子孫のすべてのクラスでバラストとして存在します。最も便利なのはComparer()メソッドです。実際には最も頻繁に上書きされます。しかし、良い意味でComparer()はインターフェースであり、CObjectの中に定義するのではなく、別のクラスとして定義する必要があります。 MQLの知識の深さには、いつも驚かされています。見てみたり、CExpertを使ってみたり、自分で授業を作るようになったりもしています。CObjectやCExpertのような高みには到達できない。 1234567891011121314...23 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ZS：ところで、スレッド全体では、いつもの揉め事で、どの話題も取材希望が一件もありませんでしたね。
最初の例の選択からして、報道の質には相応の疑問がある
彼らが何者で、 何を学んで いないのか、もっと具体的に説明できないか。モデレーターは掃除の仕方など勉強していない )
ZS：ところで、スレッド全体では、いつものように、どのトピックをカバーするために単一の願いを見なかった、いつものようにわだかまり。そこで、せめて何かの役に立てばと思い、OOPの仕組みを一からYouTubeで動画撮影することにしました。とにかく、しばらくするとブランチがbranch_suckerで終わってしまうのです。
もっと正確に 言うと、彼らはOOPの使い方を学んでいないのです。
アレクセイ、あなたはOOPを単純に学ぶことができないことを自分自身でよく理解していると思います。継承、カプセル化、ポリモーフィズムなど、OOPの正式な知識はよく繰り返されますが、誰かがそれらを暗記し、MMモジュールから継承するExpertクラスなど、暴力的かつ不適切に適用することによる害は、益々多くなります（SB開発者の皆さんこんにちは:)。
MQLに関しては、OOPの観点からは非常に弱い言語 です。型制御は全くなく（少なくとも安全な変換はできました）、リフレクションは初期段階にあり非常に限定的で、インターフェースは全くありません。MQLでどのようなOOPを教えることができるのか、という疑問が生まれます。開発者自身がStandard Libraryを 滅茶苦茶にしているのだから、時には怖いくらいだとしたら、何と言えばいいのだろう。
もっと正確に言うと、 私たちはOOPを学んでいないのです。
アレクセイ、あなたはOOPを学ぶだけではダメだということをよく分かっていると思います。継承、カプセル化、ポリモーフィズムなど、OOPの正式な知識はよく繰り返されますが、誰かがそれらを暗記し、MMモジュールから継承するExpertクラスなど、暴力的で不適切な適用による害の方が多いのです（SB開発者の皆さん、こんにちは：）。
MQLに関しては、OOPの観点からは非常に弱い言語 です。型制御は全くなく（少なくとも安全な変換はできました）、リフレクションは初期段階にあり非常に限定的で、インターフェースは全くありません。MQLでどのようなOOPを教えることができるのか、という疑問が生まれます。開発者自身がStandard Libraryの ようなハンパなものを成形してしまうと、時には怖い思いをすることもあるので、何と言うか。
確かに弱いですが、中程度の深刻さのプロジェクトならまだ可能です。SBは、さまざまな人がさまざまなレベルのトレーニングを受けています。そして、肝心なところが欠けています。私は今でも貴社のCDictionaryを使っていますが、マスト・デューのことです。
さあ、どうする、横になって死ぬのか？))やっぱりDELLに入るかもしれません。
OOPを学ぶことができるのではないでしょうか。自分で覚えたんです。そして、他の人もそうでした。
そして、まだOOPを学ぶことができると思います。自分で覚えたんです。そして、それは他の人たちも同じです。
だから、正しい事例から学ぶ必要があるのです。でも、SBにはないんです。CObjectは型の制御を提供せず、オブジェクトとのインターフェースレベルの作業も提供せず、Save()やLoad()のような実際には再定義されることのない無意味なメソッドを含んでいるのです。m_prev と m_next ポインタは、単一のCList クラスで 使用されますが、その子孫のすべてのクラスでバラストとして存在します。最も便利なのはComparer()メソッドです。実際には最も頻繁に上書きされます。しかし、良い意味でComparer()はインターフェースであり、CObjectの中に定義するのではなく、別のクラスとして定義する必要があります。
どうやらstaticとconst（これはOOPではない）は必要ないようです。
OOPに関しては、実用性の高い（抽象的でない）次の関数が手続き型になるとどうなるのか、非常に興味深いですね。
もちろん、どんなOOPも手続き型に書き換えることは可能です。でも、練習には興味があります。そこで、OOPも最低限使われている上記のような小さなコードをとってみました。
では、この例で、手続き型はOOPと比較して、どれだけすっきりしているか／便利か／読みやすいか／正しいか？さて、数ページにわたって話をするわけではありませんが、短いソースコードの手続き型とOOPを比較するだけです。OOPの対戦相手には、名人芸を見せてもらう。これは、恐るべきMT5ではなく、古き良きMT4です。
同じようにプログラミングを学ぶにはどうしたらいいのでしょうか？:) とてもいい感じです。
あるいは、考え方を変える必要があるのかもしれません。
例えば、構造体がクラスとほぼ同じようにコンストラクタで使用できることは知りませんでした。
例えば、構造体がクラスとほぼ同じようにコンストラクタで使用できることを知りませんでした。
全く同じようにプログラミングを学べる金型は？とてもいい感じです。
とか、自分の意識も変える必要があるのかもしれません。
例えば、構造体がコンストラクタでほとんどクラスのように使用できることは知りませんでした。
また、fxsaberのコードのどこが天才的なのか、お聞かせください。IsChangeの副作用に魅了されたのかもしれませんし、システムの状態をユーザーレベルで複製しなければならないという考えなのかもしれません。
fxsaberのコードのどこが天才的なのか、お聞かせください。IsChangeの副作用に魅了されたのか、それともシステムの状態をユーザーレベルで複製すべきだという考えなのか？
おそらく、私はこのコードをほとんど理解していないためです :)
すみません、私はプログラマーとしては素人なので...OOPは基本的なレベルしか知らないのですが...。
C++では、クラスと構造体は同じで、いくつかのデフォルトが異なるだけです。
かっこいい！知らなかった...もっとプロを勉強しないといけないのかな。
だから、正しい事例から学ぶ必要があるのです。しかもSBにはない。CObjectを例にとると、型制御を提供せず、オブジェクトとのインターフェースレベルの作業も提供せず、Save()やLoad()のような実際には決してオーバーライドされない無意味なメソッドを含んでいるのです。m_prev と m_next ポインタは、単一のCList クラスで 使用されますが、その子孫のすべてのクラスでバラストとして存在します。最も便利なのはComparer()メソッドです。実際には最も頻繁に上書きされます。しかし、良い意味でComparer()はインターフェースであり、CObjectの中に定義するのではなく、別のクラスとして定義する必要があります。