私のアプローチコアはエンジンです。 - ページ 87 1...808182838485868788899091929394...184 新しいコメント Реter Konow 2018.12.18 16:12 #861 Vasiliy Sokolov: s.s. 特にMTオブジェクトに文字列を格納する件ですが、1つだけ奇妙な不具合があります。データの圧縮を開始し、オブジェクト名に未印刷の文字を使用すると、場合によってはそのオブジェクトにアクセスできなくなることがあります。この不具合は非常に特殊で、知っている人も少ないので、おそらくまだ残っていると思いますが、それでもつまずくことがあるかもしれません。なるほど、練習あるのみですね。 Nikolai Semko 2018.12.19 06:12 #862 Реter Konow:対戦相手の皆様へ。 以下は、そのスクリプトコードです。 文字列をChar配列に 転送し、リソース経由で他のプログラムに渡すための時間、およびその後の情報の分割・取得のためにChar配列から文字列を取り出す時間を測定します。その後の情報の分割・検索のために、MTオブジェクト記述に文字列を書き込む時間、MTオブジェクト記述から文字列を取り出す時間を測定する。結果 ピーター、あなたはテストする場所を間違えていますよ。あなたがテストしているものは、文字列の論理的にはほぼ同じ速度であるはずです。 あなたは私のメッセージを完全に誤解しています。 私が言いたかったのは、double,long,time,intなどを文字列で渡すのはやめなさいということです。また、テキストを渡す必要がある場合は、テキスト文字列をuchar配列に変換してください。そして、ユニオンデータ構造、またはユニオンでuint配列に変換されたこれらの構造の配列を介して異なるタイプのすべての混合データは、リソースを通過し、受信側ではこれらのuint配列はユニオンを介して元の構造に変換されなければならない。ピーター、Tバックはとても遅いから、可能な限り避けなければならないよ。文字列は、テキストとプリント出力にのみ必要です。 そして、あなたの例では、パフォーマンスの測定という概念を完全に間違えています。 特にOBJPROP_TEXTプロパティを通じて、最大サイズ63バイトの文字列を渡すことができます。これは何でもないことです。 あなたの例は全く意味がありませんが、私は純粋にデモンストレーションの目的で、より正しいものに修正しました。 スクリプトコードを添付します。MT4とMT5の両方で動作します MT4です。 2018.12.19 00:50:14.542 TestStringVsCharArray NZDUSD,Weekly: время через свойство объекта: 2309 правильность копирования - true 2018.12.19 00:50:14.542 TestStringVsCharArray NZDUSD,Weekly: время через uchar массив: 1882 правильность копирования - true MT5です。 2018.12.19 00:32:30.857 TestStringVsCharArray (NZDUSD,M1) время через свойство объекта: 32811 правильность копирования - true 2018.12.19 00:33:00.678 TestStringVsCharArray (NZDUSD,M1) время через uchar массив: 364 правильность копирования - true MT5は非同期式らしいので、あなたの方法は100倍遅くなり、MT5には全く向いていません。MT5をもっともっと重視すべき そして、それは何なのか？ StringToCharArray(qwerty,Arr,0,WHOLE_ARRAY);少なくともヘルプは読むべき ファイル: TestStringVsCharArray.mq4 6 kb Aliaksandr Hryshyn 2018.12.19 06:25 #863 Реter Konow:対戦相手の皆様へ。 以下は、そのスクリプトコードです。 文字列をChar配列に 転送し、リソース経由で他のプログラムに渡すための時間と、Char配列から文字列を取り出し、その後の情報の分割や取り出しにかかる時間を測定します。その後の情報の分割・検索のために、MTオブジェクト記述に文字列を書き込む時間、MTオブジェクト記述から文字列を取り出す時間を測定する。結果 よく読んで結論を出そう https://docs.mql4.com/ru/basis/types/stringconst結論に至るまで1.文字列中の各文字に対して2バイトを確保、Unicodeエンコーディング。弦楽器の容量を十分に活用できていない。2.CharArrayToString関数（およびその逆）を使用する場合、uchar配列内の文字のエンコーディングに応じた変換が行われ、これもCPU時間を食います。ShortArrayToStringを使用する（逆も同様）。ただし、Unicodeでは、文字列はゼロで終わらなければならないことに注意してください。 Nikolai Semko 2018.12.19 06:38 #864 Aliaksandr Hryshyn: よく読んで結論を出そう https://docs.mql4.com/ru/basis/types/stringconst結論から言うと、私が手伝います。1.文字列中の各文字に対して2バイトを確保、Unicodeエンコーディング。弦楽器の容量を十分に活用できていない。2.CharArrayToString関数（およびその逆）を使用する場合、uchar配列内の文字のエンコーディングに応じた変換が行われ、これもCPU時間を食います。ShortArrayToStringを使用する（逆も同様）。ただし、Unicodeでは文字列はnullで終わらなければならないことに注意してください。は納得いかない。文字列の中間値としてuchar配列が必要です。また、変換は行わず、バイトをコピーしているだけです。 Aliaksandr Hryshyn 2018.12.19 06:56 #865 Nikolai Semko:納得がいきません。中間値として文字列のuchar配列が必要です。また、変換は行わず、バイトのコピーを行うだけです。 キリル文字の通過を試みる。そして、uchar配列の文字コードと文字列の文字コードを比較し、文字列はushort配列として渡されます。 Nikolai Semko 2018.12.19 07:13 #866 Aliaksandr Hryshyn: キリル文字を使うようにする。また、uchar配列と文字列の文字コードを比較すると、文字列はushort配列のようなものです。ユニコードって知ってる。しかし、今回のケースでは、uchar配列が必要なのは、unionを通してuint配列を取得し、それをさらにリソースに渡して、文字列回復のチェーンを取得するときだけです。損はさせません。また、この場合、uchar配列から文字を抽出する必要はありません。エンコーディングは変更可能で、デフォルトではnon-unicodeである。 Реter Konow 2018.12.19 07:26 #867 Nikolai Semko:ピーター、あなたはテストする場所を間違えていますよ。あなたがテストしているものは、文字列の論理的にはほぼ同じ速度であるはずです。ニコライ、失礼ながら、それは何のための空言だ。測定してスクリプトを添付しました。「正しい方法、間違った方法...」「文字列の論理的にほぼ同じ速度になるはず」...。言葉だけでいい。 ニコライ・セムコ ... あなたは私のメッセージを完全に誤解しています。 私が言いたかったのは、double、long、time、intなどを渡すのに文字列を使うのはやめなさいということです。また、テキストを渡す必要がある場合は、テキスト文字列をuchar配列に変換してください。そして、ユニオンを介した異種混合のデータ構造、またはユニオンを介してuint配列に変換されたこれらの構造体の配列は、リソースを介して渡され、受信側ではこれらのuint配列はユニオンを介して元の構造体に変換されて戻される必要があります。ピーター、Tバックはとても遅いから、可能な限り避けなければならないよ。文字列は、テキストとプリント出力にのみ必要です。 まさに、あなたのメッセージは完璧に理解できました。と間違っている。 なぜ？- なぜなら、 制御 パラメータを扱うシステムをLOTに複雑化 しなければならないからです。パラメータの保存、受け渡し、管理のアーキテクチャは、TUCH より複雑で混乱し、多くの問題や全体的な速度低下を招くことになるでしょう。 内部アーキテクチャを理解していないプログラムがどのように相互作用し、パラメータ値をその種類や特性に応じて管理するのかがわからない。あなたの提案は、事態をより複雑に、より混乱させるでしょう。そして、コミュニケーションの問題を解決することはできません。まだ、クラッチのままでしょう。 ニコライ・セムコ： ...さらに、OBJPROP_TEXTプロパティを通して、最大サイズ63バイトの文字列を渡すことができます。それは何でもない。あなたの例は全く意味がありませんが、純粋にデモンストレーションのためにもっと正しいものに作り直しました。サイズ63バイトの1000種類の文字列をコピーすると、次のようになります。... 1つのMT-objectの説明文に64文字の文字列を渡すことができます。もういいよ。大きなテーブルのデータを転送するために、20～30行必要です。大きなテーブルがなければ、せいぜい2～3行でいいんです。 今、MT4に興味があります。 MT5は常に発展しています。開発者は、MTプログラムの共通メモリを追加するだけで、（リソースに煩わされることなく）疑問は解消されるのです。 Реter Konow 2018.12.19 07:35 #868 Nikolai Semko: ... 私が言いたかったのは、double,long,time,intなどを文字列で渡すのはやめましょうということです。 ... double,long,time,intなどの転送はどのように行うのですか？??? これをリソースに書き込むには、文字列に変換し、さらにcharに変換する必要があることは同じです。 それとも、lparam,dparamを使うのが良いのでしょうか？ つまり、イベントキューをオーバーロードする...。 Nikolai Semko 2018.12.19 07:35 #869 Реter Konow: ガッカリだ。話がそれてしまいましたが。幼稚園、第2四半期無教養で無知で偉そうな態度は うんざりだ Реter Konow 2018.12.19 07:39 #870 Nikolai Semko: また、計測の際に、リソースを保存して読む時間を加えるのを忘れていますね...。 つまり、1000行書いても（本当はリソースを通した方が良いのですが）、リソースの保存と取得にコストがかかるため、速度が上がりません。 1...808182838485868788899091929394...184 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
s.s. 特にMTオブジェクトに文字列を格納する件ですが、1つだけ奇妙な不具合があります。データの圧縮を開始し、オブジェクト名に未印刷の文字を使用すると、場合によってはそのオブジェクトにアクセスできなくなることがあります。この不具合は非常に特殊で、知っている人も少ないので、おそらくまだ残っていると思いますが、それでもつまずくことがあるかもしれません。
なるほど、練習あるのみですね。
対戦相手の皆様へ。
以下は、そのスクリプトコードです。
結果
ピーター、あなたはテストする場所を間違えていますよ。あなたがテストしているものは、文字列の論理的にはほぼ同じ速度であるはずです。
あなたは私のメッセージを完全に誤解しています。
私が言いたかったのは、double,long,time,intなどを文字列で渡すのはやめなさいということです。また、テキストを渡す必要がある場合は、テキスト文字列をuchar配列に変換してください。そして、ユニオンデータ構造、またはユニオンでuint配列に変換されたこれらの構造の配列を介して異なるタイプのすべての混合データは、リソースを通過し、受信側ではこれらのuint配列はユニオンを介して元の構造に変換されなければならない。ピーター、Tバックはとても遅いから、可能な限り避けなければならないよ。文字列は、テキストとプリント出力にのみ必要です。
そして、あなたの例では、パフォーマンスの測定という概念を完全に間違えています。
特にOBJPROP_TEXTプロパティを通じて、最大サイズ63バイトの文字列を渡すことができます。これは何でもないことです。
あなたの例は全く意味がありませんが、私は純粋にデモンストレーションの目的で、より正しいものに修正しました。
スクリプトコードを添付します。MT4とMT5の両方で動作します
MT4です。
MT5です。
MT5は非同期式らしいので、あなたの方法は100倍遅くなり、MT5には全く向いていません。MT5をもっともっと重視すべき
そして、それは何なのか？
少なくともヘルプは読むべき
対戦相手の皆様へ。
以下は、そのスクリプトコードです。
結果
よく読んで結論を出そう https://docs.mql4.com/ru/basis/types/stringconst
は納得いかない。文字列の中間値としてuchar配列が必要です。また、変換は行わず、バイトをコピーしているだけです。
納得がいきません。中間値として文字列のuchar配列が必要です。また、変換は行わず、バイトのコピーを行うだけです。
キリル文字を使うようにする。また、uchar配列と文字列の文字コードを比較すると、文字列はushort配列のようなものです。
ユニコードって知ってる。しかし、今回のケースでは、uchar配列が必要なのは、unionを通してuint配列を取得し、それをさらにリソースに渡して、文字列回復のチェーンを取得するときだけです。損はさせません。また、この場合、uchar配列から文字を抽出する必要はありません。
エンコーディングは変更可能で、デフォルトではnon-unicodeである。
ピーター、あなたはテストする場所を間違えていますよ。あなたがテストしているものは、文字列の論理的にはほぼ同じ速度であるはずです。
ニコライ、失礼ながら、それは何のための空言だ。測定してスクリプトを添付しました。「正しい方法、間違った方法...」「文字列の論理的にほぼ同じ速度になるはず」...。言葉だけでいい。
ニコライ・セムコ
...
あなたは私のメッセージを完全に誤解しています。
私が言いたかったのは、double、long、time、intなどを渡すのに文字列を使うのはやめなさいということです。また、テキストを渡す必要がある場合は、テキスト文字列をuchar配列に変換してください。そして、ユニオンを介した異種混合のデータ構造、またはユニオンを介してuint配列に変換されたこれらの構造体の配列は、リソースを介して渡され、受信側ではこれらのuint配列はユニオンを介して元の構造体に変換されて戻される必要があります。ピーター、Tバックはとても遅いから、可能な限り避けなければならないよ。文字列は、テキストとプリント出力にのみ必要です。
まさに、あなたのメッセージは完璧に理解できました。と間違っている。
なぜ？- なぜなら、 制御 パラメータを扱うシステムをLOTに複雑化 しなければならないからです。パラメータの保存、受け渡し、管理のアーキテクチャは、TUCH より複雑で混乱し、多くの問題や全体的な速度低下を招くことになるでしょう。
内部アーキテクチャを理解していないプログラムがどのように相互作用し、パラメータ値をその種類や特性に応じて管理するのかがわからない。あなたの提案は、事態をより複雑に、より混乱させるでしょう。そして、コミュニケーションの問題を解決することはできません。まだ、クラッチのままでしょう。
...
さらに、OBJPROP_TEXTプロパティを通して、最大サイズ63バイトの文字列を渡すことができます。それは何でもない。
あなたの例は全く意味がありませんが、純粋にデモンストレーションのためにもっと正しいものに作り直しました。サイズ63バイトの1000種類の文字列をコピーすると、次のようになります。
...
1つのMT-objectの説明文に64文字の文字列を渡すことができます。もういいよ。大きなテーブルのデータを転送するために、20～30行必要です。大きなテーブルがなければ、せいぜい2～3行でいいんです。
今、MT4に興味があります。
MT5は常に発展しています。開発者は、MTプログラムの共通メモリを追加するだけで、（リソースに煩わされることなく）疑問は解消されるのです。
Nikolai Semko:
...
私が言いたかったのは、double,long,time,intなどを文字列で渡すのはやめましょうということです。
...
double,long,time,intなどの転送はどのように行うのですか？???
これをリソースに書き込むには、文字列に変換し、さらにcharに変換する必要があることは同じです。
それとも、lparam,dparamを使うのが良いのでしょうか？
つまり、イベントキューをオーバーロードする...。
また、計測の際に、リソースを保存して読む時間を加えるのを忘れていますね...。
つまり、1000行書いても（本当はリソースを通した方が良いのですが）、リソースの保存と取得にコストがかかるため、速度が上がりません。