野心的なアイデア ! - ページ 4 123456789 新しいコメント Andrei01 2010.11.11 14:44 #31 TheXpert: 落ち着いてください。 なぜ突然？盲目的な信仰心は傷つくのか？:) Igor Makanu 2010.11.11 14:46 #32 Andrei01: なぜ、ナンセンスなのか？正しいデータや関数にたどり着くまでに、いくつのポインタが必要かを計算するだけです。 確かに数え方を知っていれば。:) 落ち着いてください、何をすればいいのですか？クラスの新しいインスタンスを作成すると、つまりクラス型の変数を作成すると、関係テーブルの複製が作成され、それで終わりです データへのアクセスは、クラス内も通常の変数内も同じ速度で、クラス内のアクセス権の分割（privat, public）に関するすべての記述的対策 - これらはすべてコンパイラレベルで、コンパイルされたコードは物理メモリセルにのみ作用します。 さて、ここでは、他の狡猾に生み出されたクラスからその場で狡猾に生み出される「複雑な動的クラス」が存在すると仮定してみましょう。それがどうした？結局、すべては特定の関数によって計算されることになる。では、そんなサーカスの芸のために、果たして庭を作る価値があったのだろうか。 病気は進行しているか？何度か言われたことがあると思いますが、OOPはプログラマをデータ準備のルーチンワークから解放し、データの中身をコントロールすることから解放し、クラス内のメソッドをどう実装するか、サードパーティの関数をどう呼び出すかはプログラマ次第です OOPも過去のものです。現在のトレンドはハードウェア指向のプログラミングで、CUDAなどC言語が中心です。GPUを搭載したプロセッサーが発売されれば、この点はさらに強化されるでしょう。プロセッサー各社は、ユニバーサル・プロセッサー・コアのみのリリースを止める予定です。 ここで私は有能ではなく、あなたの口では、この情報は信頼性がないと思われる SZZY：私があなたに書く理由は、技術フォーラムで無意味なことを書かず、自分の知識を共有し、わからないことがあれば私に聞くことです。 Andrei01 2010.11.11 14:54 #33 IgorM: クラスの新しいインスタンス、つまりクラス型の変数を作成すると、関係テーブルの複製が作成され、それでおしまいです。 データへのアクセスは、クラスでも普通の変数でも速度は同じ、クラス内のアクセス権を分ける記述的な手段（privat, public）はすべてコンパイラレベル、コンパイルされたコードは物理メモリセルでのみ動作する では、ここで専門家に質問です。3つの動的配列（コンパイル時のサイズは不明）からなるクラスがあります。 ここで、クラス内の任意の静的配列と動的配列にアクセスする際の演算数を計算し、比較してみてください。 Andrei01 2010.11.11 15:14 #34 IgorM: 私はここで有能ではありませんし、あなたの口では、この情報は信頼性がないと思われる しかし、情報の信頼性は、それを提示する人によって決まるのでしょうか？情報とは主観的なものではなく、客観的なものであることは、良識ある人であれば理解できるはずです。:) Alexey Subbotin 2010.11.11 15:39 #35 Andrei01: プログラムのロジックとデータの表現にはどんな関係があるのでしょうか？これらはまったくつながっていない。 プログラムロジックは、任意の入力データに対する算術演算であり、データ表現は、あるフォーマットまたは別のフォーマットによる単なるデータである。 また、内部データ（関数や変数）に直接アクセスするのではなく、オブジェクトへの外部ポインタが登場するため、定義上、OOPではプログラムコードを削減することは不可能です。しかし、ポインタやメモリ参照の計算は非常に遅い処理であるため、性能はそれに応じて低下する。 OOPアプリケーションの開発は、クラスライブラリの開発と同じではありません。厳密に言えば、ライブラリの開発者は、アプリケーション・プログラムを書く人が自分のライブラリを何に使うかを全く気にする必要はない。例えば、ハンマーメーカーは、釘を打つため、ナッツを割るため、といった使い方を全く気にしません。彼の仕事は、道具を作ることです。また、OOPでは、クラスはある範囲のタスクを解決するためのツールであり、通常は非常に幅広く、常に明確に定義されているわけではありません（ゴキブリを殺すためにハンマーを使うかもしれませんね）。 もう一度言いますが、最も単純なタスクを解決するためには、OOPは必要ありません。しかし一方で、釘を打ちたい人がみんな自分でハンマーを作らなければならないとは思っていないでしょう？ もちろん、「すでに関数ライブラリがあるのに、なぜこれ以上クラスが必要なのか」と反論することもできます。 しかし、この場合、継承機構、型拡張、オーバーロードなどが提供する便利な機能を自分で取り除いてしまうことになる。大雑把に言えば、ハンマーに自作のモーターをねじ込んで自分流に動かすことはできますが、ハンマーの機構を理解する必要はなく、釘を打つことができればいいのです。 だから、OOPはアプリケーションを書くプログラマーにとって、本当に人生を楽にしてくれるものだと信じています。もうひとつは、MQL5ライブラリの機能はまだ 非常に限られていますが、時間の問題で、ライブラリ開発者が対応してくれるでしょう（もちろん、同じ人であっても構いませんが、そうである必要はありません）。クラスライブラリが充実していれば、「1.プログラム、ここにデータがあります」「2.プログラム、カウントしてください」と1、2行書くだけで、ほとんど疑問なくプログラムが動くようになります。これは構造指向プログラミングでは実現できない。 OOPに対する偏見は、十分に複雑なタスクに出会ったことがないか、単に怠惰などの理由でやりたくないかのどちらかだと思われます。何もしないのに、そう言ってしまう。しかし、マスターはマスターです。 Igor Makanu 2010.11.11 16:17 #36 Andrei01: ここで、専門家の質問を紹介します。3つの動的配列（コンパイル時のサイズは不明）からなるクラスがあります。 ここで、クラス内の任意の静的配列と動的配列にアクセスする際の操作回数を計算し、比較してみてください。 クラスと何の関係があるのでしょうか？ 動的配列や静的配列を扱うわけですが、動的配列を 使うのにクラスの中や変数の中だけというのは関係ありません。 動的配列の処理に少し時間がかかるのは「当たり前」です。配列のオーバーランに対する制御があり、動的メモリ割り当てマネージャはしばしば Andrei01 2010.11.11 16:22 #37 alsu: 1.しかし、その場合、継承、型拡張、オーバーロードなどのメカニズムが提供する利便性が損なわれてしまう。大雑把に言えば、ハンマーに手製のモーターをボルトで固定して、自分流に動かすことはできますが、ハンマーの仕組みを理解する必要はなく、それで釘を打てればいいのです。 2.クラスライブラリのシステムが充実していれば、ユーザープログラマーは、プログラムの中に「1.プログラム、ここにデータがあります」「2.プログラム、カウントしてください」と1、2行書くだけで、ほとんど詳しい仕組みは聞かずに済むのです。構造指向プログラミングでは、これは実現できない。 1.RPPでは、クラスが具体的に何をするのか、ということも扱わなければなりません。まるで何かの機能であるかのように。しかし、クラスの場合、チェーン全体をトレースすることは難しいので、一般的には、同じ機能レベルであれば、その構造の研究に多くの時間が費やされます。 2.構造指向プログラミングでは、このような動作も問題なく整理することができ、誰かが既に行ったことのあるような細部にまで踏み込む必要はない。 Andrei01 2010.11.11 16:29 #38 IgorM: 動的配列と静的配列の使い分けは、クラスでも変数でも同じです。 よし、もっとシンプルに質問しよう。1次元配列と2次元配列の変数にアクセスするときの操作回数を比較することができます。 なのに、ほとんど差がないって言い張るの？ Igor Makanu 2010.11.11 16:42 #39 Andrei01: なるほど、ではもっと簡単な質問をします。1次元配列と2次元配列の変数にアクセスするときの操作回数を比較することができます。 ほとんど差がないと言い張るつもりですか？ これもOOPの質問ですか？ 多次元配列の データは文字列でメモリに格納されるため、配列 x[20] と配列 y[2][10] がある場合、y データはまず y[0] 、次に y[1] とメモリに記録され、物理的には x[20] と同じ場所に配置されることになるからです。 性能上の遅延があったとしても、それは配列のオーバーラン制御のためにのみ発生するものであり、重要なものではありません。 配列が動的な場合、それは特定のコンパイラメーカーに依存します - メモリマネージャのコードのどのくらいが最適化されているか（Delphiでは、システムモジュールのほとんどはASMで書かれています）、多次元動的配列のメモリ割り当てが少し複雑になるので、しかし、通常、問題は動的配列にではなく、プログラマにあります - 彼は動的配列のメモリ割り当てを正当かつ頻繁に呼び出す方法 SZS：チャットありがとうございます - しかし、私はそんなに時間を費やすために、初歩的な物事の理解のあなたの不足のためにできません - 自分で読み始める Andrei01 2010.11.11 17:03 #40 IgorM: これもOOPの質問ですか？ 配列が静的な場合 - 多次元配列のデータは文字列としてメモリに格納されるため，1次元配列と2次元配列の両方にアクセスしても性能に違いはありません． 簡単なことも知らないので、間違っています。 どのような配列のデータでも、メモリには線形に格納されます。最初から最後まで、ある要素 x[15] にアクセスするには、この変数を計算するために、配列の先頭のアドレスにオフセット 15 を加えたものを計算します。例えば2次元の配列、x[2][5]があった場合、まず2行目のオフセットを計算し、それに5番目の要素のオフセットを加える、つまり2倍の演算を行うことになるのです。 123456789 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
落ち着いてください。
なぜ、ナンセンスなのか？正しいデータや関数にたどり着くまでに、いくつのポインタが必要かを計算するだけです。
確かに数え方を知っていれば。:)
落ち着いてください、何をすればいいのですか？クラスの新しいインスタンスを作成すると、つまりクラス型の変数を作成すると、関係テーブルの複製が作成され、それで終わりです
データへのアクセスは、クラス内も通常の変数内も同じ速度で、クラス内のアクセス権の分割（privat, public）に関するすべての記述的対策 - これらはすべてコンパイラレベルで、コンパイルされたコードは物理メモリセルにのみ作用します。
さて、ここでは、他の狡猾に生み出されたクラスからその場で狡猾に生み出される「複雑な動的クラス」が存在すると仮定してみましょう。それがどうした？結局、すべては特定の関数によって計算されることになる。では、そんなサーカスの芸のために、果たして庭を作る価値があったのだろうか。
病気は進行しているか？何度か言われたことがあると思いますが、OOPはプログラマをデータ準備のルーチンワークから解放し、データの中身をコントロールすることから解放し、クラス内のメソッドをどう実装するか、サードパーティの関数をどう呼び出すかはプログラマ次第です
OOPも過去のものです。現在のトレンドはハードウェア指向のプログラミングで、CUDAなどC言語が中心です。GPUを搭載したプロセッサーが発売されれば、この点はさらに強化されるでしょう。プロセッサー各社は、ユニバーサル・プロセッサー・コアのみのリリースを止める予定です。
ここで私は有能ではなく、あなたの口では、この情報は信頼性がないと思われる
SZZY：私があなたに書く理由は、技術フォーラムで無意味なことを書かず、自分の知識を共有し、わからないことがあれば私に聞くことです。
クラスの新しいインスタンス、つまりクラス型の変数を作成すると、関係テーブルの複製が作成され、それでおしまいです。
データへのアクセスは、クラスでも普通の変数でも速度は同じ、クラス内のアクセス権を分ける記述的な手段（privat, public）はすべてコンパイラレベル、コンパイルされたコードは物理メモリセルでのみ動作する
では、ここで専門家に質問です。3つの動的配列（コンパイル時のサイズは不明）からなるクラスがあります。
ここで、クラス内の任意の静的配列と動的配列にアクセスする際の演算数を計算し、比較してみてください。
私はここで有能ではありませんし、あなたの口では、この情報は信頼性がないと思われる
プログラムのロジックとデータの表現にはどんな関係があるのでしょうか？これらはまったくつながっていない。
プログラムロジックは、任意の入力データに対する算術演算であり、データ表現は、あるフォーマットまたは別のフォーマットによる単なるデータである。
また、内部データ（関数や変数）に直接アクセスするのではなく、オブジェクトへの外部ポインタが登場するため、定義上、OOPではプログラムコードを削減することは不可能です。しかし、ポインタやメモリ参照の計算は非常に遅い処理であるため、性能はそれに応じて低下する。
OOPアプリケーションの開発は、クラスライブラリの開発と同じではありません。厳密に言えば、ライブラリの開発者は、アプリケーション・プログラムを書く人が自分のライブラリを何に使うかを全く気にする必要はない。例えば、ハンマーメーカーは、釘を打つため、ナッツを割るため、といった使い方を全く気にしません。彼の仕事は、道具を作ることです。また、OOPでは、クラスはある範囲のタスクを解決するためのツールであり、通常は非常に幅広く、常に明確に定義されているわけではありません（ゴキブリを殺すためにハンマーを使うかもしれませんね）。
もう一度言いますが、最も単純なタスクを解決するためには、OOPは必要ありません。しかし一方で、釘を打ちたい人がみんな自分でハンマーを作らなければならないとは思っていないでしょう？
もちろん、「すでに関数ライブラリがあるのに、なぜこれ以上クラスが必要なのか」と反論することもできます。 しかし、この場合、継承機構、型拡張、オーバーロードなどが提供する便利な機能を自分で取り除いてしまうことになる。大雑把に言えば、ハンマーに自作のモーターをねじ込んで自分流に動かすことはできますが、ハンマーの機構を理解する必要はなく、釘を打つことができればいいのです。
だから、OOPはアプリケーションを書くプログラマーにとって、本当に人生を楽にしてくれるものだと信じています。もうひとつは、MQL5ライブラリの機能はまだ 非常に限られていますが、時間の問題で、ライブラリ開発者が対応してくれるでしょう（もちろん、同じ人であっても構いませんが、そうである必要はありません）。クラスライブラリが充実していれば、「1.プログラム、ここにデータがあります」「2.プログラム、カウントしてください」と1、2行書くだけで、ほとんど疑問なくプログラムが動くようになります。これは構造指向プログラミングでは実現できない。
OOPに対する偏見は、十分に複雑なタスクに出会ったことがないか、単に怠惰などの理由でやりたくないかのどちらかだと思われます。何もしないのに、そう言ってしまう。しかし、マスターはマスターです。
ここで、専門家の質問を紹介します。3つの動的配列（コンパイル時のサイズは不明）からなるクラスがあります。
ここで、クラス内の任意の静的配列と動的配列にアクセスする際の操作回数を計算し、比較してみてください。
クラスと何の関係があるのでしょうか？ 動的配列や静的配列を扱うわけですが、動的配列を 使うのにクラスの中や変数の中だけというのは関係ありません。
動的配列の処理に少し時間がかかるのは「当たり前」です。配列のオーバーランに対する制御があり、動的メモリ割り当てマネージャはしばしば
alsu:
1.しかし、その場合、継承、型拡張、オーバーロードなどのメカニズムが提供する利便性が損なわれてしまう。大雑把に言えば、ハンマーに手製のモーターをボルトで固定して、自分流に動かすことはできますが、ハンマーの仕組みを理解する必要はなく、それで釘を打てればいいのです。
2.クラスライブラリのシステムが充実していれば、ユーザープログラマーは、プログラムの中に「1.プログラム、ここにデータがあります」「2.プログラム、カウントしてください」と1、2行書くだけで、ほとんど詳しい仕組みは聞かずに済むのです。構造指向プログラミングでは、これは実現できない。
1.RPPでは、クラスが具体的に何をするのか、ということも扱わなければなりません。まるで何かの機能であるかのように。しかし、クラスの場合、チェーン全体をトレースすることは難しいので、一般的には、同じ機能レベルであれば、その構造の研究に多くの時間が費やされます。
2.構造指向プログラミングでは、このような動作も問題なく整理することができ、誰かが既に行ったことのあるような細部にまで踏み込む必要はない。
動的配列と静的配列の使い分けは、クラスでも変数でも同じです。
よし、もっとシンプルに質問しよう。1次元配列と2次元配列の変数にアクセスするときの操作回数を比較することができます。
なのに、ほとんど差がないって言い張るの？
なるほど、ではもっと簡単な質問をします。1次元配列と2次元配列の変数にアクセスするときの操作回数を比較することができます。
ほとんど差がないと言い張るつもりですか？
これもOOPの質問ですか？
多次元配列の データは文字列でメモリに格納されるため、配列 x[20] と配列 y[2][10] がある場合、y データはまず y[0] 、次に y[1] とメモリに記録され、物理的には x[20] と同じ場所に配置されることになるからです。
性能上の遅延があったとしても、それは配列のオーバーラン制御のためにのみ発生するものであり、重要なものではありません。
配列が動的な場合、それは特定のコンパイラメーカーに依存します - メモリマネージャのコードのどのくらいが最適化されているか（Delphiでは、システムモジュールのほとんどはASMで書かれています）、多次元動的配列のメモリ割り当てが少し複雑になるので、しかし、通常、問題は動的配列にではなく、プログラマにあります - 彼は動的配列のメモリ割り当てを正当かつ頻繁に呼び出す方法
SZS：チャットありがとうございます - しかし、私はそんなに時間を費やすために、初歩的な物事の理解のあなたの不足のためにできません - 自分で読み始める
これもOOPの質問ですか？
配列が静的な場合 - 多次元配列のデータは文字列としてメモリに格納されるため，1次元配列と2次元配列の両方にアクセスしても性能に違いはありません．
簡単なことも知らないので、間違っています。
どのような配列のデータでも、メモリには線形に格納されます。最初から最後まで、ある要素 x[15] にアクセスするには、この変数を計算するために、配列の先頭のアドレスにオフセット 15 を加えたものを計算します。例えば2次元の配列、x[2][5]があった場合、まず2行目のオフセットを計算し、それに5番目の要素のオフセットを加える、つまり2倍の演算を行うことになるのです。