私のアプローチコアはエンジンです。 - ページ 98 1...919293949596979899100101102103104105...184 新しいコメント Vasiliy Sokolov 2018.12.21 11:47 #971 そのヒントとして、ZIPアーカイブの構造を見て ください。単純な構造とデータで構成されています。同じような構造は、データの転送に最適かもしれませんね。なお、ZIPアーカイブには1行もありませんが、これは、異なる名前のファイルが何百とあるミニチュアファイルシステムを完璧に表示することを妨げるものではありません。 Реter Konow 2018.12.21 11:54 #972 Vasiliy Sokolov: そのヒントとして、zip アーカイブの構造を ご覧ください。単純な構造とデータで構成されています。同様の構造は、データ転送にも有効でしょう。なお、ZIPアーカイブには1行もありませんが、これは名前の異なる数百のファイルを持つミニチュアファイルシステムを完璧に表示することを妨げているわけではありません。プロフェッショナルな視点での課題に賛成です。MTオブジェクトによる文字列転送よりも、バイト転送の方が深刻そうです。 問題は、どれだけ実現可能性があるかということです。 転送されるデータのサイズや種類は事前にわからない。どのように実装するのか？ Vasiliy Sokolov 2018.12.21 12:00 #973 Реter Konow:プロフェッショナルな視点での課題に賛成です。MTオブジェクトによる文字列転送よりも、バイト転送の方が深刻そうです。 問題は、どれだけ実現可能性があるかということです。 転送するデータのサイズや種類は事前にわからない。ユニオンを導入するには？可能なんです。 ZIPの構造を詳しく研究してください。理解は得られるだろう。梱包前のファイルサイズは不明です。ファイル名は異なる長さでもかまいません。また、ファイル数が大きく異なることもあります。それにもかかわらず、ZIPはデータを参照する有限構造の厳密な型付けされたセットを表します。 どの構造を扱う必要があるかがわかれば、ユニオンはそれらの構造をバイトで表現しているだけなので、ユニオンに問題はない。 Реter Konow 2018.12.21 12:04 #974 Vasiliy Sokolov:可能です。ZIPの構造を詳しく研究する。理解は得られるだろう。そこでは、パックする前のファイルのサイズは不明です。ファイル名にはさまざまな長さがあります。また、ファイル数が大きく異なることもあります。それにもかかわらず、ZIPはデータを参照する有限構造の厳密な型付けされたセットを表します。どのような構造を扱う必要があるかがわかれば、その構造をバイトで表現すればよいのですから、問題はありません。なるほど、でも、たとえば組合がなくてもやっていけるのでは？ 各イベントで、EAはメッセージ文字列を収集し、それにはすべてのタイプの変更されたパラメータとその値が含まれる。そして、この文字列を StringToCharでバイト配列に 変換し、リソースに書き込む。そして、逆の開梱を行います。 当初は、このようなリソースを使った解決策を想像していました。ただし、文字列を組み立て、分割する必要があります。 Реter Konow 2018.12.21 12:06 #975 とにかくソリューションにリソースがないとダメなんです。そこで問題は、文字列のパースをどう回避するかです。可能だと思うんですね。正直言って疑問です。でも、否定はしない...。 Vasiliy Sokolov 2018.12.21 12:15 #976 Реter Konow:OK、でも、例えばユニオン抜きではダメなのでは？ 各イベントで、EAはすべてのタイプの変更されたパラメータとその値を含むメッセージ文字列を収集する。そして、この文字列をStringToCharでバイト配列に変換し、リソースに書き込む。そして、逆の開梱を行います。 当初は、このようなリソースを使った解決策を想像していました。ただし、組み立てと紐の分割が必要です。ユニオンは、構造体をバイトまたはintで同時に表現するもので、同じものである。Unionは、バイト配列に構造体を投影しているようですが、バイト配列は同時に構造体の集合でもあります。リソースがint型配列の場合、バイト配列から構造体配列への変換とその逆の操作を追加で行う必要はない。これは時間の節約になります。 p.s. この方式では、メッセージソースはデータをリソースにコピーするのではなく、データを直接変更し、その変更が一度にリソースに反映されます。そのため、文字列から 配列、配列から文字列への変換と その後の解析が延々と続くのではなく、直接データを扱うことができます。このデータは、ResourceReadImage を使用する受信者にのみコピーされる。 Реter Konow 2018.12.21 12:24 #977 Vasiliy Sokolov:ユニオンは、構造体をバイトまたはintで同時に表現するもので、同じものである。Unionは、バイト配列に構造体を投影するもので、バイト配列は同時に構造体の集合体でもあります。リソースがint型配列の場合、バイト配列から構造体配列への変換とその逆の操作を追加で行う必要はない。時間の節約になります。考えてみないと...。もしかしたら、おっしゃるとおり、ユニオンで実装することは可能かもしれませんね。 例えば、パラメータ値を設定するたびに、その値をバイトの配列に変換するような場合です。より正確には、すべてのユーザーパラメータは、ユニオンに属するべきです。そして、バイト単位で反映されたそのコピーが、すぐにリソースへの書き込みに利用できるようになる。 Vasiliy Sokolov 2018.12.21 12:26 #978 Реter Konow:例えば、パラメータ値を設定するたびに、その値をバイトの配列に変換 する。より正確には、すべてのユーザーパラメータはユニオンに属さなければならない。そして、そのバイトが反映されたコピーがすぐにリソースに書き込めるようになる。はい、その通りです。あなたが書き込んだ前の記事に、私はすでにpsで返信しました :)つまり、長いコピーや変換ではなく、正確にマッピング する作業をしているのです。 Реter Konow 2018.12.21 12:27 #979 つまり、ユーザーパラメータの値を変更するたびに、その値を単位変数の値に変換して、すぐに共通のバイト配列に保存し、それをuintに変換してリソースに書き込む必要があります。 Реter Konow 2018.12.21 12:31 #980 Vasiliy Sokolov:はい、その通りです。あなたがこれを書いたとき、私はすでに前の投稿のpsで返信しました:)つまり、長いコピーや変換ではなく、正確にマッピング する作業をしているのです。しかし、テキストはどうでしょうか？ StringToChar() でバイトに変換する必要があります。ユニオンは使えないんですよね？ 1...919293949596979899100101102103104105...184 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
そのヒントとして、zip アーカイブの構造を ご覧ください。単純な構造とデータで構成されています。同様の構造は、データ転送にも有効でしょう。なお、ZIPアーカイブには1行もありませんが、これは名前の異なる数百のファイルを持つミニチュアファイルシステムを完璧に表示することを妨げているわけではありません。
プロフェッショナルな視点での課題に賛成です。MTオブジェクトによる文字列転送よりも、バイト転送の方が深刻そうです。
問題は、どれだけ実現可能性があるかということです。
転送されるデータのサイズや種類は事前にわからない。どのように実装するのか？
プロフェッショナルな視点での課題に賛成です。MTオブジェクトによる文字列転送よりも、バイト転送の方が深刻そうです。
問題は、どれだけ実現可能性があるかということです。
転送するデータのサイズや種類は事前にわからない。ユニオンを導入するには？
可能なんです。
ZIPの構造を詳しく研究してください。理解は得られるだろう。梱包前のファイルサイズは不明です。ファイル名は異なる長さでもかまいません。また、ファイル数が大きく異なることもあります。それにもかかわらず、ZIPはデータを参照する有限構造の厳密な型付けされたセットを表します。
どの構造を扱う必要があるかがわかれば、ユニオンはそれらの構造をバイトで表現しているだけなので、ユニオンに問題はない。
可能です。
ZIPの構造を詳しく研究する。理解は得られるだろう。そこでは、パックする前のファイルのサイズは不明です。ファイル名にはさまざまな長さがあります。また、ファイル数が大きく異なることもあります。それにもかかわらず、ZIPはデータを参照する有限構造の厳密な型付けされたセットを表します。
どのような構造を扱う必要があるかがわかれば、その構造をバイトで表現すればよいのですから、問題はありません。
なるほど、でも、たとえば組合がなくてもやっていけるのでは？
各イベントで、EAはメッセージ文字列を収集し、それにはすべてのタイプの変更されたパラメータとその値が含まれる。そして、この文字列を StringToCharでバイト配列に 変換し、リソースに書き込む。そして、逆の開梱を行います。
当初は、このようなリソースを使った解決策を想像していました。ただし、文字列を組み立て、分割する必要があります。
OK、でも、例えばユニオン抜きではダメなのでは？
各イベントで、EAはすべてのタイプの変更されたパラメータとその値を含むメッセージ文字列を収集する。そして、この文字列をStringToCharでバイト配列に変換し、リソースに書き込む。そして、逆の開梱を行います。
当初は、このようなリソースを使った解決策を想像していました。ただし、組み立てと紐の分割が必要です。
ユニオンは、構造体をバイトまたはintで同時に表現するもので、同じものである。Unionは、バイト配列に構造体を投影しているようですが、バイト配列は同時に構造体の集合でもあります。リソースがint型配列の場合、バイト配列から構造体配列への変換とその逆の操作を追加で行う必要はない。これは時間の節約になります。
p.s. この方式では、メッセージソースはデータをリソースにコピーするのではなく、データを直接変更し、その変更が一度にリソースに反映されます。そのため、文字列から 配列、配列から文字列への変換と その後の解析が延々と続くのではなく、直接データを扱うことができます。このデータは、ResourceReadImage を使用する受信者にのみコピーされる。
ユニオンは、構造体をバイトまたはintで同時に表現するもので、同じものである。Unionは、バイト配列に構造体を投影するもので、バイト配列は同時に構造体の集合体でもあります。リソースがint型配列の場合、バイト配列から構造体配列への変換とその逆の操作を追加で行う必要はない。時間の節約になります。
考えてみないと...。もしかしたら、おっしゃるとおり、ユニオンで実装することは可能かもしれませんね。
例えば、パラメータ値を設定するたびに、その値をバイトの配列に変換するような場合です。より正確には、すべてのユーザーパラメータは、ユニオンに属するべきです。そして、バイト単位で反映されたそのコピーが、すぐにリソースへの書き込みに利用できるようになる。
例えば、パラメータ値を設定するたびに、その値をバイトの配列に変換 する。より正確には、すべてのユーザーパラメータはユニオンに属さなければならない。そして、そのバイトが反映されたコピーがすぐにリソースに書き込めるようになる。
はい、その通りです。あなたが書き込んだ前の記事に、私はすでにpsで返信しました :)つまり、長いコピーや変換ではなく、正確にマッピング する作業をしているのです。
はい、その通りです。あなたがこれを書いたとき、私はすでに前の投稿のpsで返信しました:)つまり、長いコピーや変換ではなく、正確にマッピング する作業をしているのです。
しかし、テキストはどうでしょうか？
StringToChar() でバイトに変換する必要があります。ユニオンは使えないんですよね？