OOPの専門家に質問です。 - ページ 5 123456789101112...55 新しいコメント Реter Konow 2019.08.25 14:16 #41 Artyom Trishkin: すべてのリストには、バイナリサーチがすでに用意されています。これは、リストを一つずつ見ていくのではなく、検索されたプロパティでフィルタリングすることを意味します。その結果、探している項目のインデックスを得ることができる。 これらのリストは、OOP内部の何かに添付されているのでしょうか？つまり、どんな "荷物 "を運んでいるのか？クラス、コンストラクター、インターフェース......？クラスの環境に溶け込んでいるんですね。 Реter Konow 2019.08.25 14:17 #42 Nikolai Semko: クラスオブジェクトが生成されると、クラスのすべてのプロパティ（変数）のためのメモリが確保される 以外に、コンストラクタの1つが起動されます（複数存在する場合もあります）。 コンストラクタには、ノンパラメトリック（デフォルト）、パラメトリック（クラスのインスタンス生成時に何らかのパラメータを指定する場合）、コピーコンストラクタ（クラスのインスタンスのパラメータに別のクラスのインスタンスを指定する場合）があります。 なるほど、ありがとうございます、ニコライさん。意識していきたいと思います。 Igor Makanu 2019.08.25 14:18 #43 Реter Konow: この課題はすでに公開で解決しています。このアイデアは、すべてのシンボルとすべてのタイムフレームのテーブルを作成し、それをループして新しいバーのイベントを修正することでした。このイベントのいずれかの関数が最初に呼び出された後、そのフラグはテーブルから消去される。OOPに比べ、どの程度複雑なのか判断がつきません。しかし、実際には、むしろシンプルで便利なソリューションです。 上に書いたように、すべては相対的なものなのです......。クリップの最後のショットを使用して... MTの標準ライブラリは OOPスタイルで、Metakvotのプログラマーがプロフェッショナルでわかりやすいスタイルを使っているか、2つのオプションがあります。あなたのバージョン ;) Реter Konow 2019.08.25 14:33 #44 Igor Makanu: 上に書いたように、すべては相対的なものなのです......。クリップの最後のショットを使用して... MTの標準ライブラリは OOPスタイルで、Metakvotのプログラマーがプロフェッショナルでわかりやすいスタイルを使っているか、2つのオプションがあります。あなたのバージョン ;) 私はまだOOPに精通しているわけではありません。リストについては教えてくれるが、何を使って「食べて」いるのかがわからない。発表の仕方、アクセスの仕方、変更の仕方などなど...。私にとってのリストは、追加の構文がないただの動的配列です。オブジェクトは、プロパティの集合を配列にしたものです。そして、OOPでは、Objectはクラス全体なのです。継承 - オブジェクトのリンク。名前付きリファレンスを通じて、オブジェクトのプロパティにアクセスする。ですから、私の場合、すべてがもっとシンプルなので、機能や効率を比較するのは難しいと感じています。もっと深く掘り下げたい でも、ひとつだけわかったことがあります。OOP全体を理解し、完全に切り替えることなく、OOPの概念から1つのエンティティを理解し、使用することはできません。OOPでも何でもいいんです。ただ、その便利な仕組みを使っても、おそらくうまくいかないでしょう。 Igor Makanu 2019.08.25 14:43 #45 Реter Konow: その便利な仕組みを利用するだけでは、おそらくうまくいかないでしょう。 しかし、関数は完全に分離・独立したコードブロックでなければならず、関数が使用するものはすべて関数内にあるか、関数にパラメータとして渡されなければなりません。 一般に、Wikiに書かれているように、OOPは手続き型の延長であること レタグ・コノウ しかし、ひとつだけ理解できたことがあります。OOP全体を理解し、完全にOOPに移行することなく、OOPのコンセプトから1つのエンティティを理解し、使用することはできません。 しかし、少なくとも便利なのは確かです。） Реter Konow 2019.08.25 14:52 #46 Igor Makanu: しかし、関数は完全に分離・独立したコードブロックでなければなりません。つまり、関数が使用するものはすべて関数内にあるか、関数にパラメータとして渡されなければなりません。 一般に、Wikiに書かれているように、OOPは手続き型スタイルの延長である でも、少なくとも便利なんです。他のタスクに完全に移行できるコードがあるのは便利です。） そう、コードのポータビリティはOOPの大きなメリットです。私の場合、個々の機能だけがポータブルですが（しかもごくまれに）、大きな機構を作るときは何もポータブルではありません。人間の臓器が（専門家の介入なしに）移植できないのと同じように。私の機構は、大きなブロックに分かれていて、それぞれが多くの仕事をこなしているという意味で、より「生物」に近いと思います。そのため、ポータビリティはほとんどありません。しかし、これらのブロックは、その機能を拡張することが非常に簡単です。数行で「追加」して、出来上がりです。- ブロックは、あなたが多くの別々の関数を書かなければならない新しい仕事の全体のレイヤーを実行します。全てに於いて、利点があります。 まあ、グローバルスコープというのは非常に強力なツールですからね。ブロックが扱う素材は絶対に手に入るものであり、何かを転送する必要はない。仕事に必要なものは、すでにすべてそろっているのです。総じて言えば、アプローチの仕方はそれぞれ異なり、それぞれの良さがあります。 Georgiy Merts 2019.08.25 14:54 #47 Реter Konow: 私はまだOOPについてよく知らないのです。リストについて教えてくれるのですが、「何を食べているのか」わからないのです。どのように宣言するか、どのようにアクセスするか、どのように変更するかなど......。私にとってのリストは、追加の構文がないただの動的配列です。オブジェクトは、プロパティの集合を配列にしたものです。そして、OOPでは、Objectはクラス全体なのです。継承 - オブジェクトのリンク。名前付きリファレンスを通じて、オブジェクトのプロパティにアクセスする。ですから、私の場合、すべてがもっとシンプルなので、機能や効率を比較するのは難しいと感じています。もっと深く掘り下げなければならない。 でも、ひとつだけわかったことがあります。OOP全体を理解し、OOPに完全に乗り換えることなく、OOPの概念から1つのエンティティを理解し、使用することはできません。 OOPでも何でもいいんです。ただ、その便利な仕組みを使っても、おそらくうまくいかないでしょう。 ピーター 試してみるしかないでしょう。なぜなら、そこには、継承、カプセル化、ポリモーフィズムという、3つの方向から見たOOPの利点がすべて見られるからです。 継承により、リスト内のオブジェクトを操作するための単一のインタフェース（仮想関数の セット）を持つことができます。オブジェクトは、ベースから継承されたシンプルなものと複雑なものがあります。 ポリモーフィズムによって、この単一のインタフェースで根本的に異なるオブジェクトを扱うことができる。 カプセル化されているため、このインターフェイスのみを持ち、実装の詳細には一切アクセスできませんので、何かを失敗させることはできません。さらに、今あるオブジェクトがどう動くかだけでなく、まだ書かれていないオブジェクトがあなたのコードとどう関わるかも正確に知っているのです。 Artyom Trishkin 2019.08.25 14:58 #48 Реter Konow: これらのリストは、OOP内の何かに添付されているのでしょうか？つまり、どんな "荷物 "を抱えているのか？クラス、コンストラクター、インターフェース......？クラスの環境に溶け込んでいるんですね。 基本的には - リストは配列に非常に近いものです。リスト型の変数として宣言するか、new 演算子 で新規に作成することができます。しかし、新規の場合、リストは端末サブシステムによって制御されていないため、作業が終了したら必ず削除する必要があります - 削除。しかし、そのようなリストがオブジェクトとして他のリストに追加された場合、監視する必要はありません。 Igor Makanu 2019.08.25 15:03 #49 Реter Konow: まあ、グローバルスコープというのは非常に強力なツールですからね。ブロックが扱う素材は、絶対に手に入るものであり、何かを移し替える必要はない。仕事に必要なものは、すべてすでにそこにある。 関数やコードセクションのパラメータとして使用される変数のグローバルスコープに関して 言えばimhoは、これは後で検出することが不可能な隠されたバグを得る可能性と完全に非輸送のコードを取得するための最良の方法です SZZ: MT4 EAのこのようなコードを何度も修正しました。最初はグローバルに宣言された変数の名前を変更し、次にコンパイラのエラーを見たときに変更しました。しかし、前回は適切に行いました。関数シグネチャに新しいパラメータを追加し、グローバルに宣言した変数を削除しました。この悲惨なコードを一度修正できたとしても、もう一度やり直さなければなりませんよね？- 私は怠け者ですが、それなりに怠け者です )))) Реter Konow 2019.08.25 15:58 #50 Igor Makanu: 関数やコードセクションのパラメータとして使用される変数のグローバルスコープに関して 言えば imhoは、これは後で検出することが不可能な隠されたバグを得る可能性と完全に非輸送のコードを取得するための最良の方法です SZZ: MT4 EAのこのようなコードを何度も修正しました。最初はグローバルに宣言された変数の名前を変更し、次にコンパイラのエラーを見たときに変更しました。しかし、前回は適切に行いました。関数シグネチャに新しいパラメータを追加し、グローバルに宣言した変数を削除しました。この悲惨なコードを一度修正できたとしても、もう一度やり直さなければならないのではありませんか？- 私は怠け者ですが、それなりに怠け者です ))))) コードは移植できないので、そこが特徴です。持ち運びを想定したものではありません。もうひとつの目的があります。さて、変数のグローバルスコープは、複雑な機構を扱う上で強力なツールです。使いこなせればいいんです。隠れたエラーやバグについて言われると、混乱してしまいます。グローバル変数の可視化に関連するバグが発生したことはありません。一言で言えば、「全然ダメ」です。 123456789101112...55 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
すべてのリストには、バイナリサーチがすでに用意されています。これは、リストを一つずつ見ていくのではなく、検索されたプロパティでフィルタリングすることを意味します。その結果、探している項目のインデックスを得ることができる。
クラスオブジェクトが生成されると、クラスのすべてのプロパティ（変数）のためのメモリが確保される 以外に、コンストラクタの1つが起動されます（複数存在する場合もあります）。 コンストラクタには、ノンパラメトリック（デフォルト）、パラメトリック（クラスのインスタンス生成時に何らかのパラメータを指定する場合）、コピーコンストラクタ（クラスのインスタンスのパラメータに別のクラスのインスタンスを指定する場合）があります。
この課題はすでに公開で解決しています。このアイデアは、すべてのシンボルとすべてのタイムフレームのテーブルを作成し、それをループして新しいバーのイベントを修正することでした。このイベントのいずれかの関数が最初に呼び出された後、そのフラグはテーブルから消去される。OOPに比べ、どの程度複雑なのか判断がつきません。しかし、実際には、むしろシンプルで便利なソリューションです。
上に書いたように、すべては相対的なものなのです......。クリップの最後のショットを使用して...
MTの標準ライブラリは OOPスタイルで、Metakvotのプログラマーがプロフェッショナルでわかりやすいスタイルを使っているか、2つのオプションがあります。あなたのバージョン ;)
上に書いたように、すべては相対的なものなのです......。クリップの最後のショットを使用して...
MTの標準ライブラリは OOPスタイルで、Metakvotのプログラマーがプロフェッショナルでわかりやすいスタイルを使っているか、2つのオプションがあります。あなたのバージョン ;)
私はまだOOPに精通しているわけではありません。リストについては教えてくれるが、何を使って「食べて」いるのかがわからない。発表の仕方、アクセスの仕方、変更の仕方などなど...。私にとってのリストは、追加の構文がないただの動的配列です。オブジェクトは、プロパティの集合を配列にしたものです。そして、OOPでは、Objectはクラス全体なのです。継承 - オブジェクトのリンク。名前付きリファレンスを通じて、オブジェクトのプロパティにアクセスする。ですから、私の場合、すべてがもっとシンプルなので、機能や効率を比較するのは難しいと感じています。もっと深く掘り下げたい
でも、ひとつだけわかったことがあります。OOP全体を理解し、完全に切り替えることなく、OOPの概念から1つのエンティティを理解し、使用することはできません。OOPでも何でもいいんです。ただ、その便利な仕組みを使っても、おそらくうまくいかないでしょう。
その便利な仕組みを利用するだけでは、おそらくうまくいかないでしょう。
しかし、関数は完全に分離・独立したコードブロックでなければならず、関数が使用するものはすべて関数内にあるか、関数にパラメータとして渡されなければなりません。
一般に、Wikiに書かれているように、OOPは手続き型の延長であること
しかし、ひとつだけ理解できたことがあります。OOP全体を理解し、完全にOOPに移行することなく、OOPのコンセプトから1つのエンティティを理解し、使用することはできません。
しかし、少なくとも便利なのは確かです。）
しかし、関数は完全に分離・独立したコードブロックでなければなりません。つまり、関数が使用するものはすべて関数内にあるか、関数にパラメータとして渡されなければなりません。
一般に、Wikiに書かれているように、OOPは手続き型スタイルの延長である
でも、少なくとも便利なんです。他のタスクに完全に移行できるコードがあるのは便利です。）
そう、コードのポータビリティはOOPの大きなメリットです。私の場合、個々の機能だけがポータブルですが（しかもごくまれに）、大きな機構を作るときは何もポータブルではありません。人間の臓器が（専門家の介入なしに）移植できないのと同じように。私の機構は、大きなブロックに分かれていて、それぞれが多くの仕事をこなしているという意味で、より「生物」に近いと思います。そのため、ポータビリティはほとんどありません。しかし、これらのブロックは、その機能を拡張することが非常に簡単です。数行で「追加」して、出来上がりです。- ブロックは、あなたが多くの別々の関数を書かなければならない新しい仕事の全体のレイヤーを実行します。全てに於いて、利点があります。 まあ、グローバルスコープというのは非常に強力なツールですからね。ブロックが扱う素材は絶対に手に入るものであり、何かを転送する必要はない。仕事に必要なものは、すでにすべてそろっているのです。総じて言えば、アプローチの仕方はそれぞれ異なり、それぞれの良さがあります。
私はまだOOPについてよく知らないのです。リストについて教えてくれるのですが、「何を食べているのか」わからないのです。どのように宣言するか、どのようにアクセスするか、どのように変更するかなど......。私にとってのリストは、追加の構文がないただの動的配列です。オブジェクトは、プロパティの集合を配列にしたものです。そして、OOPでは、Objectはクラス全体なのです。継承 - オブジェクトのリンク。名前付きリファレンスを通じて、オブジェクトのプロパティにアクセスする。ですから、私の場合、すべてがもっとシンプルなので、機能や効率を比較するのは難しいと感じています。もっと深く掘り下げなければならない。
でも、ひとつだけわかったことがあります。OOP全体を理解し、OOPに完全に乗り換えることなく、OOPの概念から1つのエンティティを理解し、使用することはできません。 OOPでも何でもいいんです。ただ、その便利な仕組みを使っても、おそらくうまくいかないでしょう。
ピーター 試してみるしかないでしょう。なぜなら、そこには、継承、カプセル化、ポリモーフィズムという、3つの方向から見たOOPの利点がすべて見られるからです。
継承により、リスト内のオブジェクトを操作するための単一のインタフェース（仮想関数の セット）を持つことができます。オブジェクトは、ベースから継承されたシンプルなものと複雑なものがあります。
ポリモーフィズムによって、この単一のインタフェースで根本的に異なるオブジェクトを扱うことができる。
カプセル化されているため、このインターフェイスのみを持ち、実装の詳細には一切アクセスできませんので、何かを失敗させることはできません。さらに、今あるオブジェクトがどう動くかだけでなく、まだ書かれていないオブジェクトがあなたのコードとどう関わるかも正確に知っているのです。
これらのリストは、OOP内の何かに添付されているのでしょうか？つまり、どんな "荷物 "を抱えているのか？クラス、コンストラクター、インターフェース......？クラスの環境に溶け込んでいるんですね。
まあ、グローバルスコープというのは非常に強力なツールですからね。ブロックが扱う素材は、絶対に手に入るものであり、何かを移し替える必要はない。仕事に必要なものは、すべてすでにそこにある。
関数やコードセクションのパラメータとして使用される変数のグローバルスコープに関して 言えばimhoは、これは後で検出することが不可能な隠されたバグを得る可能性と完全に非輸送のコードを取得するための最良の方法です
SZZ: MT4 EAのこのようなコードを何度も修正しました。最初はグローバルに宣言された変数の名前を変更し、次にコンパイラのエラーを見たときに変更しました。しかし、前回は適切に行いました。関数シグネチャに新しいパラメータを追加し、グローバルに宣言した変数を削除しました。この悲惨なコードを一度修正できたとしても、もう一度やり直さなければなりませんよね？- 私は怠け者ですが、それなりに怠け者です ))))
関数やコードセクションのパラメータとして使用される変数のグローバルスコープに関して 言えば imhoは、これは後で検出することが不可能な隠されたバグを得る可能性と完全に非輸送のコードを取得するための最良の方法です
SZZ: MT4 EAのこのようなコードを何度も修正しました。最初はグローバルに宣言された変数の名前を変更し、次にコンパイラのエラーを見たときに変更しました。しかし、前回は適切に行いました。関数シグネチャに新しいパラメータを追加し、グローバルに宣言した変数を削除しました。この悲惨なコードを一度修正できたとしても、もう一度やり直さなければならないのではありませんか？- 私は怠け者ですが、それなりに怠け者です )))))
コードは移植できないので、そこが特徴です。持ち運びを想定したものではありません。もうひとつの目的があります。さて、変数のグローバルスコープは、複雑な機構を扱う上で強力なツールです。使いこなせればいいんです。隠れたエラーやバグについて言われると、混乱してしまいます。グローバル変数の可視化に関連するバグが発生したことはありません。一言で言えば、「全然ダメ」です。