私のアプローチコアはエンジンです。 - ページ 2 123456789...184 新しいコメント Igor Makanu 2018.12.05 12:35 #11 を超えることができなかった...このような横長のコードの束を見るには、どのようなモニター解像度が必要でしょうか? エディタを見ながら、スクロールして コードを編集したり表示したりするのは快適ではありません ))) Реter Konow 2018.12.05 12:36 #12 といった具合に。 私のアプローチの利点は、まず「簡潔さ」です。言葉を減らして、数字を増やす。オブジェクトは ベクトルである。項目は、行列内のベクトルの複合体である。 エレメントの複合 体が「窓」です。窓の複合 体が「コア」です。 要は、Objectはグラフィカルである必要はないのです。要素はNotionと することができ、少なからずObjectとPropertyを付与することができる。そしてエンジンは、これらの概念(Element)を扱う論理的な機械となる。 Georgiy Merts 2018.12.05 12:36 #13 Vasiliy Sokolov:OOPは非常に柔軟な方法論なので、「カーネル」という概念のような先験的な考え方はありません。しかし、ここで問題になっているカーネルモデルは、OOPを使って構築することも十分に可能です。したがって、この文は完全に正しいとは言えません。はい、自分で調べてみて、驚きました。ピーターはOOPのことをそのまま表現しているんです。 しかし、私が理解したところでは、Peterは威厳として、Kernelのすべてのプロパティとメソッドにフルアクセスできるユーザーの能力を引き出しているのです。そして、OOPスタイルはまさにカプセル化であり、あらゆる方法でアクセス権が制限されている場合です。 私も若い頃、プロテクトモードではパソコンのメモリに全部アクセスできないことに、ひどく憤慨したのを覚えています。プログラムが起動しても、そのメモリにアクセスできないことがあるのですが......。ダイレクトメモリアクセスコントローラをプログラミングすることで、プログラムからアクセスできない別プロセスのメモリの内容まで取得できる「回避策」を特別に構築した(ただし、このためにはRAPコントローラのポートにアクセスするコマンドを使用しなければならず、これ自体がマルチタスクのWindows環境では簡単ではないので、専用のドライバを使用した)。 そしてその時初めて、プロテクトモードやアクセス共有(そして一般的なカプセル化)が、私に必要な非常に重要なものだと理解したのです。間違って入ってはいけないものに入らないようにするためです。そして今、私は「今、プロセスに必要な資源、性質、方法だけが、プログラムのどの場所でも利用可能でなければならない」という立場にしっかりと立っています。 しかし、私が理解するところでは、ピーターはカプセル化を提唱しているわけではありません。 Реter Konow 2018.12.05 12:37 #14 Igor Makanu:を超えることができなかった...このような横長のコードの束を見るには、どのようなモニター解像度が必要でしょうか? エディタを見て、コードを編集したり表示したりするのに何度もスクロールするのは不快です )))先ほども言いましたが、私のアプローチは利便性がメインではありません。要は効率と開発・応用の可能性ですね。 Igor Makanu 2018.12.05 12:39 #15 Реter Konow:先ほども言いましたが、私のアプローチでは利便性がメインではありません。要は効率と開発・応用の可能性です。OK、もっとコードの例を待ってみますが、今のところ、非常に読みにくいコードしか 見当たりません。 Реter Konow 2018.12.05 12:41 #16 Vasiliy Sokolov:OOPは非常に柔軟な方法論なので、「カーネル」という概念のような先験的な考え方はありません。しかし、ここで問題になっているカーネルモデルは、OOPを使って構築することも十分に可能です。したがって、この文は完全に正しいとは言えません。条件付きカーネルを構築することができる。真面目な番組はそうだと思います。しかし、私はすべてを「物理的」なカーネルの上に構築しています。 Реter Konow 2018.12.05 12:45 #17 Igor Makanu:OK、もっとコードの例を待ってみますが、今のところ、非常に読みにくいコードしか 見当たりません。見てください。表示されているのはあくまで一般的な例です。ここで、より分かりやすく説明します。 ボタン(Button)を描きたい。配列を作成し、作成したいボタンのプロパティ値を格納します。ボタンは、Base、Text、Pictureの 3つのオブジェクトから構成されています。各オブジェクトはボタン要素の中に存在するため、配列は2次元でなければなりません。配列の各行は、ボタン要素の1つのオブジェクトを表します。3つのオブジェクトがボタン全体を表現することになります。こうして、3つのベクトルからなる行列ができあがり、それぞれが1つのボタンオブジェクトのプロパティを担っています。 そして、このマトリックスを原型として 使用することができます。他のボタンが作成される際のテンプレート。最終的なバリアントで変更する必要があるのは、オブジェクトのいくつかの値だけで、新しいボタンが作成されます。 基本的には、OOPでも同じことができます。しかし、クラスはテンプレートとして使用 されます。 配列はテンプレートとして使って います。 そこが違うところです。 Aliaksandr Hryshyn 2018.12.05 12:49 #18 Реter Konow:先ほども言いましたが、私のアプローチでは利便性がメインではありません。要は効率と開発・応用の可能性ですね。 開発の可能性は利便性にも左右される。 Vladimir Karputov 2018.12.05 12:50 #19 この「ポルタポッティ」(#9)をチェックできるコードはどこにあるのでしょうか? Nikolai Semko 2018.12.05 12:58 #20 Vladimir Karputov: この「ボロボロ」(#9)をチェックするためのコードはどこにあるのでしょうか? コード、少なくともex4-fileは来てください。今のところMT4程度と理解しています。 123456789...184 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
を超えることができなかった...このような横長のコードの束を見るには、どのようなモニター解像度が必要でしょうか?
エディタを見ながら、スクロールして コードを編集したり表示したりするのは快適ではありません )))
といった具合に。
私のアプローチの利点は、まず「簡潔さ」です。言葉を減らして、数字を増やす。オブジェクトは ベクトルである。項目は、行列内のベクトルの複合体である。 エレメントの複合 体が「窓」です。窓の複合 体が「コア」です。
要は、Objectはグラフィカルである必要はないのです。要素はNotionと することができ、少なからずObjectとPropertyを付与することができる。そしてエンジンは、これらの概念(Element)を扱う論理的な機械となる。
OOPは非常に柔軟な方法論なので、「カーネル」という概念のような先験的な考え方はありません。しかし、ここで問題になっているカーネルモデルは、OOPを使って構築することも十分に可能です。したがって、この文は完全に正しいとは言えません。
はい、自分で調べてみて、驚きました。ピーターはOOPのことをそのまま表現しているんです。
しかし、私が理解したところでは、Peterは威厳として、Kernelのすべてのプロパティとメソッドにフルアクセスできるユーザーの能力を引き出しているのです。そして、OOPスタイルはまさにカプセル化であり、あらゆる方法でアクセス権が制限されている場合です。
私も若い頃、プロテクトモードではパソコンのメモリに全部アクセスできないことに、ひどく憤慨したのを覚えています。プログラムが起動しても、そのメモリにアクセスできないことがあるのですが......。ダイレクトメモリアクセスコントローラをプログラミングすることで、プログラムからアクセスできない別プロセスのメモリの内容まで取得できる「回避策」を特別に構築した(ただし、このためにはRAPコントローラのポートにアクセスするコマンドを使用しなければならず、これ自体がマルチタスクのWindows環境では簡単ではないので、専用のドライバを使用した)。
そしてその時初めて、プロテクトモードやアクセス共有(そして一般的なカプセル化)が、私に必要な非常に重要なものだと理解したのです。間違って入ってはいけないものに入らないようにするためです。そして今、私は「今、プロセスに必要な資源、性質、方法だけが、プログラムのどの場所でも利用可能でなければならない」という立場にしっかりと立っています。
しかし、私が理解するところでは、ピーターはカプセル化を提唱しているわけではありません。
を超えることができなかった...このような横長のコードの束を見るには、どのようなモニター解像度が必要でしょうか?
エディタを見て、コードを編集したり表示したりするのに何度もスクロールするのは不快です )))
先ほども言いましたが、私のアプローチは利便性がメインではありません。要は効率と開発・応用の可能性ですね。
先ほども言いましたが、私のアプローチでは利便性がメインではありません。要は効率と開発・応用の可能性です。
OK、もっとコードの例を待ってみますが、今のところ、非常に読みにくいコードしか 見当たりません。
OOPは非常に柔軟な方法論なので、「カーネル」という概念のような先験的な考え方はありません。しかし、ここで問題になっているカーネルモデルは、OOPを使って構築することも十分に可能です。したがって、この文は完全に正しいとは言えません。
条件付きカーネルを構築することができる。真面目な番組はそうだと思います。しかし、私はすべてを「物理的」なカーネルの上に構築しています。
OK、もっとコードの例を待ってみますが、今のところ、非常に読みにくいコードしか 見当たりません。
見てください。表示されているのはあくまで一般的な例です。ここで、より分かりやすく説明します。
こうして、3つのベクトルからなる行列ができあがり、それぞれが1つのボタンオブジェクトのプロパティを担っています。
そして、このマトリックスを原型として 使用することができます。他のボタンが作成される際のテンプレート。最終的なバリアントで変更する必要があるのは、オブジェクトのいくつかの値だけで、新しいボタンが作成されます。
基本的には、OOPでも同じことができます。しかし、クラスはテンプレートとして使用 されます。 配列はテンプレートとして使って います。
そこが違うところです。
先ほども言いましたが、私のアプローチでは利便性がメインではありません。要は効率と開発・応用の可能性ですね。
この「ボロボロ」(#9)をチェックするためのコードはどこにあるのでしょうか?