私のアプローチコアはエンジンです。 - ページ 14 1...789101112131415161718192021...184 新しいコメント Реter Konow 2018.12.06 15:18 #131 Aliaksandr Hryshyn:フォーマットはシンプルなのですが、それでうまくいっていない。オブジェクトにプロパティがたくさんある場合ということです。 実際に使用されている、あなたのアプローチの例です。原理は同じです。テキストのレキシカル・パース、手作業でやるのは大変なんですよ。自動化のみ。そして、便利だなんて言わないでください。 表示されているプロトタイプの配列は、Objectのプロパティを デフォルト値で手動で初期化した結果です。開発者だけが見ることができる。 メインカーネル - エレメントプロトタイプから自動的にコンパイルされます。そして、プロトタイプは具体的な要素に変換されます。も自動的に。 コンストラクタの操作については、簡単なキーワードと便利な描画の形式があります。そこには、そのようなテーブルはありません。 Aliaksandr Hryshyn 2018.12.06 15:20 #132 Реter Konow:こちらも、あなたの考えにぴったりの例です。ただ、ダイナミックな要素が多いですね。全体の戦略、例では3つあります。ここには、利便性がないんです。添付ファイルでは ファイル: Strategy_All.txt 8 kb Реter Konow 2018.12.06 15:20 #133 Vasiliy Sokolov:つまり、配列の次元を 維持するために、一部のオブジェクトは偽のプロパティを持つことになります。自由度が高いので、何も言えません。残念ですが、この不便さは一時的に我慢していただくしかありません。一方、2次元カーネルは、ループを組み込んだり、非常に便利で高速なアクセスが可能です。一次元カーネルを作れば、"偽物 "の特性はなくなる。しかし、利便性は何倍も低くなってしまう。あるいは、単純にテキストとアイコンのプロパティをいくつかのCoreプロパティに入れることもできます。そして、問題は解消されるのです。今後、そうしていきたいと思います。 Реter Konow 2018.12.06 15:22 #134 Aliaksandr Hryshyn:もうひとつ、あなたの考えに合う例を挙げましょう。ただ、ダイナミックな要素が多いですね。全体の戦略、例では3つあります。ここには、利便性がないんです。添付ファイルでは私のアプローチは、プログラマーの利便性を追求したものではないことを、最初に読者にお断りしておきます。最強・最速のプログラム開発の構想を提案します。 もちろん、既成のブロックを差し込むのが一番早くプログラムを開発できると言われるでしょう。はい、しかし、プログラムの質は下がり、オーバーヘッドが大きくなります。ブロックの結合は、効率という点ではベストな解決策とは言えません。 Aliaksandr Hryshyn 2018.12.06 15:25 #135 Реter Konow:私は当初、私のアプローチがプログラマーの利便性を重視していないことを読者に警告した。最もパワフルで最速のプログラム開発というコンセプトを提供します。プログラマーが直接そのようなデータを修正／作成しない場合に便利である。 このようなデータを扱うコードを使うと、かなり便利です。 Dmitry Fedoseev 2018.12.06 15:27 #136 Реter Konow:私は当初、私のアプローチがプログラマーの利便性を重視していないことを読者に警告した。最もパワフルで最速のプログラム開発というコンセプトを提供します。プログラマーの利便性の低さと、プログラムの開発スピードの速さ、この2つの条件がどうして共存できるのだろうか。不便な中で、いかに早くプログラムを開発するか。 Vitalii Ananev 2018.12.06 15:27 #137 Реter Konow:コントロールすることの何が問題なのでしょうか？プロパティを追加し、Kernelの行のサイズを大きくする。以上です。また、長方形ではなく、円形や三角形のボタンが必要になった場合はどうするのでしょうか。 OOPを 使う場合は、ボタンの描画を担当する抽象メソッドDrafを持つベースクラスButtonを作成します。丸いボタンの場合は、Buttonの後継者を作り、Drafメソッドをオーバーライドして丸いボタンの描画を実装すれば十分でしょう。また、矩形のボタンについては、Buttonの後継を作り、Drafメソッドをオーバーライドして描画することで十分です。 あなたのメソッドを使うと、どんな感じになるのでしょうか？ Maxim Kuznetsov 2018.12.06 15:28 #138 Aliaksandr Hryshyn:こちらも、あなたの考えにぴったりの例です。ただ、ダイナミックな要素が多いですね。全体の戦略、例では3つあります。ここには、利便性がないんです。添付ファイルではまさか！？ 美しいものです...スタッキング可能なオートマトンです。 アセンブラとForthの最小限の知識で、簡単に読むことができます。コメントがあれば、MQLより複雑なことはない。 Реter Konow 2018.12.06 15:28 #139 Aliaksandr Hryshyn:プログラマーが直接そのようなデータを変更/作成しない場合に便利です。 このようなデータを扱うコードを使うと、かなり便利です。プロトタイプの配列が一度作成されるのがわかると思います。そして、VERY REVELATIVEに変更されます。プログラムに重大な変更がある場合のみ。 Aliaksandr Hryshyn 2018.12.06 15:30 #140 Maxim Kuznetsov:まさか！？ 美しいものです...クリアスタックマシン。 アセンブラとForthを少しでも知っていれば、すぐに読めます。コメントがあれば、MQLより複雑なことはない。かっこいいギズモです（笑)。アセンブラよりもMQLの方がプログラムを書きやすいというのは、ご納得いただけたようですね。使い勝手、効率の話です。 1...789101112131415161718192021...184 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
フォーマットはシンプルなのですが、それでうまくいっていない。オブジェクトにプロパティがたくさんある場合ということです。
実際に使用されている、あなたのアプローチの例です。原理は同じです。テキストのレキシカル・パース、手作業でやるのは大変なんですよ。自動化のみ。そして、便利だなんて言わないでください。
表示されているプロトタイプの配列は、Objectのプロパティを デフォルト値で手動で初期化した結果です。開発者だけが見ることができる。
メインカーネル - エレメントプロトタイプから自動的にコンパイルされます。そして、プロトタイプは具体的な要素に変換されます。も自動的に。
コンストラクタの操作については、簡単なキーワードと便利な描画の形式があります。そこには、そのようなテーブルはありません。
こちらも、あなたの考えにぴったりの例です。ただ、ダイナミックな要素が多いですね。全体の戦略、例では3つあります。ここには、利便性がないんです。添付ファイルでは
つまり、配列の次元を 維持するために、一部のオブジェクトは偽のプロパティを持つことになります。自由度が高いので、何も言えません。
残念ですが、この不便さは一時的に我慢していただくしかありません。一方、2次元カーネルは、ループを組み込んだり、非常に便利で高速なアクセスが可能です。一次元カーネルを作れば、"偽物 "の特性はなくなる。しかし、利便性は何倍も低くなってしまう。あるいは、単純にテキストとアイコンのプロパティをいくつかのCoreプロパティに入れることもできます。そして、問題は解消されるのです。今後、そうしていきたいと思います。
もうひとつ、あなたの考えに合う例を挙げましょう。ただ、ダイナミックな要素が多いですね。全体の戦略、例では3つあります。ここには、利便性がないんです。添付ファイルでは
私のアプローチは、プログラマーの利便性を追求したものではないことを、最初に読者にお断りしておきます。最強・最速のプログラム開発の構想を提案します。
もちろん、既成のブロックを差し込むのが一番早くプログラムを開発できると言われるでしょう。はい、しかし、プログラムの質は下がり、オーバーヘッドが大きくなります。ブロックの結合は、効率という点ではベストな解決策とは言えません。
私は当初、私のアプローチがプログラマーの利便性を重視していないことを読者に警告した。最もパワフルで最速のプログラム開発というコンセプトを提供します。
プログラマーが直接そのようなデータを修正／作成しない場合に便利である。
このようなデータを扱うコードを使うと、かなり便利です。
私は当初、私のアプローチがプログラマーの利便性を重視していないことを読者に警告した。最もパワフルで最速のプログラム開発というコンセプトを提供します。
プログラマーの利便性の低さと、プログラムの開発スピードの速さ、この2つの条件がどうして共存できるのだろうか。不便な中で、いかに早くプログラムを開発するか。
コントロールすることの何が問題なのでしょうか？プロパティを追加し、Kernelの行のサイズを大きくする。以上です。
また、長方形ではなく、円形や三角形のボタンが必要になった場合はどうするのでしょうか。
OOPを 使う場合は、ボタンの描画を担当する抽象メソッドDrafを持つベースクラスButtonを作成します。丸いボタンの場合は、Buttonの後継者を作り、Drafメソッドをオーバーライドして丸いボタンの描画を実装すれば十分でしょう。また、矩形のボタンについては、Buttonの後継を作り、Drafメソッドをオーバーライドして描画することで十分です。
あなたのメソッドを使うと、どんな感じになるのでしょうか？
こちらも、あなたの考えにぴったりの例です。ただ、ダイナミックな要素が多いですね。全体の戦略、例では3つあります。ここには、利便性がないんです。添付ファイルでは
まさか！？
美しいものです...スタッキング可能なオートマトンです。
アセンブラとForthの最小限の知識で、簡単に読むことができます。コメントがあれば、MQLより複雑なことはない。
プログラマーが直接そのようなデータを変更/作成しない場合に便利です。
このようなデータを扱うコードを使うと、かなり便利です。
プロトタイプの配列が一度作成されるのがわかると思います。そして、VERY REVELATIVEに変更されます。プログラムに重大な変更がある場合のみ。
まさか！？
美しいものです...クリアスタックマシン。
アセンブラとForthを少しでも知っていれば、すぐに読めます。コメントがあれば、MQLより複雑なことはない。
かっこいいギズモです（笑)。アセンブラよりもMQLの方がプログラムを書きやすいというのは、ご納得いただけたようですね。使い勝手、効率の話です。