私のアプローチコアはエンジンです。 - ページ 5 123456789101112...184 新しいコメント pavlick_ 2018.12.06 09:44 #41 何の話ですか？なぜカーネルは構造体／クラス（ウィンドウ、ボタンなど）の配列を含むことができないのでしょうか？(修辞的）。 テレビではなく、ラジオの部品をバケツで買うか？それと同じで、カーネルは細かいことを気にする必要はないんです。でも、それはあなた次第、便利ならいいんですよ〜。 Реter Konow 2018.12.06 09:53 #42 このエンジンは、私が「フォーカスエレメント」と呼んでいる手法でCoreと連携しています（あまり良い名前ではないかもしれません）。 考え方は次のとおりです。 グラフ上でカーソルを移動させることで、オブジェクトの境界を越えることができる。各項目は、チャートスペースに独自の領域を持ちます。カーソルの座標を監視し、カーソルがどのWindow、Elementにあるかをマークする特殊機能。 カーネル内のウィンドウとエレメントの番号がグローバル変数 に書き込まれます。そして、エンジンはこれらを使ってカーネルにアクセスし、カーソルがあるWindow、Element、Objectのプロパティの現在値をすべて取得する。 イベント（クリック、プッシュダウン、ダブルクリックなど）が発生すると、このイベントを処理するブロックは、どのウィンドウで、どの要素で、このイベントが発生したかをすぐに知ることができます。 ウィンドウ、エレメント、オブジェクトの主要なプロパティは、すでにフォーカスされており（つまりグローバル変数に格納済み）、コード内ですぐに使用されます。 これは非常に効果的です。 そのため、Kernelは単純なグローバル配列であるべきなのです。 Dmitry Fedoseev 2018.12.06 09:59 #43 Реter Konow:... だから、カーネルは単純なグローバル配列であるべきなのだ。ポインタ配列は自然界では古くから知られている。 車輪を再発明するほどの労力か...。それがすべて、より良い形で提供されているのです。 OOPの面白いところは、人に心理的な抵抗感を与えることです。クラスを書かなくても、使うだけでいい場合も。 なぜ、1つのカーネルに限定するのか。このカーネルアプローチからすれば、OOPは狂言回し的なカーネルジェネレーターに過ぎない。 Реter Konow 2018.12.06 10:03 #44 Dmitry Fedoseev:ポインタ配列は自然界では古くから知られている。 車輪の再発明に費やすほどの労力か......。このように、現実的には必要のない余分な構文を使う必要があるのです。このような構文や余分なツールを必要としないソリューションです。 この解決策は原始的なほど シンプルですが、非常に効果的です。これはまさに私が目指していることです。 Реter Konow 2018.12.06 10:10 #45 Dmitry Fedoseev:なぜ、単一のカーネルに限定するのか。このカーネルアプローチからすれば、OOPは狂言回し的なカーネルジェネレーターに過ぎない。Solutionが必要としないのに、なぜここでOOPなのか？ Windows、Element、ObjectはKernelの中で表現され、順序付けされています。これらは、配列のインデックス またはElementsのフォーカスを通してアクセスされます。 ポインタ、参照、クラス、コンストラクタ、デストラクタなど、なぜSolutionがすでに存在するのに100万ものものがあるのでしょうか？ シンプルで自給自足なのです。 OOPが必要なのは、それとはまったく別の目的なのです。もし、この技術を他の開発者とチームを組んで作り、各自が作業の一部だけを行うのであれば、OOPは必要でしょう。 Igor Makanu 2018.12.06 10:16 #46 Реter Konow:OOPは全く別の目的のためにある。もし、この技術を他の開発者とチームを組んで作り、各自が作業の一部だけを行うのであれば、OOPは必要でしょう。さんではTC、あなたの考えをコードで例示して、OOPが「悪」であることを後で議論しましょう・・・。よく言われるように、テーブルの上のコードです。))) Реter Konow 2018.12.06 10:16 #47 一つのプログラムを開発する開発者チームがスムーズに連携するために、OOPは必要なのです。開発チームが書いたコードを理解し、変更するためには、OOPが必要です。しかし、プログラマーが一人しかおらず、彼のタスクがOOPを 必要としない場合は、OOPは不要です。 pavlick_ 2018.12.06 10:17 #48 何かを完成させようとしながら、2カ月も休んでしまうと、技術に溺れてしまうのです。また、スケーリングの複雑さが明らかにされていないので、あなたのコンストラクタは十分に洗練されていないのでしょう。 Реter Konow 2018.12.06 10:17 #49 Igor Makanu:さんでは、あなたの考えをコードで例示して、OOPが「悪」であることは後で議論しましょう...。よく言われるように、テーブルの上のコードです。)))はい、簡単な例を用意します。 Dmitry Fedoseev 2018.12.06 10:44 #50 Реter Konow:一つのプログラムを開発する開発者チームがスムーズに連携するために、OOPは必要なのです。開発チームが書いたコードを理解し、変更するためには、OOPが必要です。しかし、プログラマーが一人しかおらず、彼のタスクがOOPを使用 する必要がない場合は、OOPは必要ないのです。どちらも間違いです。 123456789101112...184 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
テレビではなく、ラジオの部品をバケツで買うか？それと同じで、カーネルは細かいことを気にする必要はないんです。でも、それはあなた次第、便利ならいいんですよ〜。
このエンジンは、私が「フォーカスエレメント」と呼んでいる手法でCoreと連携しています（あまり良い名前ではないかもしれません）。
考え方は次のとおりです。
グラフ上でカーソルを移動させることで、オブジェクトの境界を越えることができる。各項目は、チャートスペースに独自の領域を持ちます。カーソルの座標を監視し、カーソルがどのWindow、Elementにあるかをマークする特殊機能。
カーネル内のウィンドウとエレメントの番号がグローバル変数 に書き込まれます。そして、エンジンはこれらを使ってカーネルにアクセスし、カーソルがあるWindow、Element、Objectのプロパティの現在値をすべて取得する。
イベント（クリック、プッシュダウン、ダブルクリックなど）が発生すると、このイベントを処理するブロックは、どのウィンドウで、どの要素で、このイベントが発生したかをすぐに知ることができます。
ウィンドウ、エレメント、オブジェクトの主要なプロパティは、すでにフォーカスされており（つまりグローバル変数に格納済み）、コード内ですぐに使用されます。
これは非常に効果的です。
そのため、Kernelは単純なグローバル配列であるべきなのです。...
だから、カーネルは単純なグローバル配列であるべきなのだ。ポインタ配列は自然界では古くから知られている。
車輪を再発明するほどの労力か...。それがすべて、より良い形で提供されているのです。
OOPの面白いところは、人に心理的な抵抗感を与えることです。クラスを書かなくても、使うだけでいい場合も。
なぜ、1つのカーネルに限定するのか。このカーネルアプローチからすれば、OOPは狂言回し的なカーネルジェネレーターに過ぎない。
ポインタ配列は自然界では古くから知られている。
車輪の再発明に費やすほどの労力か......。
このように、現実的には必要のない余分な構文を使う必要があるのです。このような構文や余分なツールを必要としないソリューションです。
この解決策は原始的なほど シンプルですが、非常に効果的です。これはまさに私が目指していることです。
なぜ、単一のカーネルに限定するのか。このカーネルアプローチからすれば、OOPは狂言回し的なカーネルジェネレーターに過ぎない。
Solutionが必要としないのに、なぜここでOOPなのか？
Windows、Element、ObjectはKernelの中で表現され、順序付けされています。これらは、配列のインデックス またはElementsのフォーカスを通してアクセスされます。
ポインタ、参照、クラス、コンストラクタ、デストラクタなど、なぜSolutionがすでに存在するのに100万ものものがあるのでしょうか？
シンプルで自給自足なのです。
OOPが必要なのは、それとはまったく別の目的なのです。もし、この技術を他の開発者とチームを組んで作り、各自が作業の一部だけを行うのであれば、OOPは必要でしょう。
OOPは全く別の目的のためにある。もし、この技術を他の開発者とチームを組んで作り、各自が作業の一部だけを行うのであれば、OOPは必要でしょう。
さんではTC、あなたの考えをコードで例示して、OOPが「悪」であることを後で議論しましょう・・・。よく言われるように、テーブルの上のコードです。)))
しかし、プログラマーが一人しかおらず、彼のタスクがOOPを 必要としない場合は、OOPは不要です。
さんでは、あなたの考えをコードで例示して、OOPが「悪」であることは後で議論しましょう...。よく言われるように、テーブルの上のコードです。)))
はい、簡単な例を用意します。
しかし、プログラマーが一人しかおらず、彼のタスクがOOPを使用 する必要がない場合は、OOPは必要ないのです。
どちらも間違いです。