mql5言語の特徴、微妙なニュアンスとテクニック - ページ 163 1...156157158159160161162163164165166167168169170...247 新しいコメント Maxim Kuznetsov 2020.01.27 01:16 #1621 Nikolai Semko: いいえ、私は気づかなかったでしょう。ただし、場合によっては（Unicodeで作業する場合）可能であることを否定はしませんが。例えば、Javaではchar型は2バイトです。 私は、このJSON ライブラリを使用する方法と、char arrayを使用する方法の2つの方法で、crypto-exchangeからのデータをパースしようと試みました。 その差は、速度にして700倍（！！）にもなることが判明した。ショックでした。おそらく、最高のJSON実装とは程遠いものだったのでしょう。 文字は16LE、文字列は明らかにpascalのものです。ちなみに、Fortranからの配列も Roman 2020.01.27 01:16 #1622 Nikolai Semko: いいえ、私は気づかなかったでしょう。ただし、場合によっては（Unicodeで作業する場合）可能であることを否定はしませんが。例えば、Javaではchar型は2バイトです。 私は、このJSON ライブラリを使用する方法と、char arrayを使用する方法の2つの方法で、crypto-exchangeからのデータをパースしようと試みました。 その差は、速度にして700倍（！！）にもなることが判明した。ショックでした。おそらく、最高のJSON実装とは程遠いものだったのでしょう。 mqlの文字列をDLLに渡すとき、DLL側ではmqlの文字列型はwchar_t*として扱われます。 また、型サイズの不一致はJavaだけでなく、アーキテクチャの種類、何だったか忘れましたが、OS、鉄にも依存します。 700回？うわー、JSONのパース用にこのライブラリ置いてたんだけど、意味ない？ また、StringToCharArrayを 変換し、ループ内で配列を解析する方が良いのでしょうか？ Nikolai Semko 2020.01.27 01:52 #1623 Roman: 700回？うわー、このライブラリはJSONのパース用に置いておいただけだから意味ないのか。 また、StringToCharArrayを 変換し、ループ内で配列を解析する方が良いのでしょうか？ そう思います、はい。常にチェックする必要がありますが。測定をしてみてください。文字列の関数が最適な方法で書かれておらず、今は修正されていることを否定はしません。 1年以上前に測ったものです。 もちろん、char配列を扱う場合、コードは大きくなりますが、可能性はより柔軟になります。 削除済み 2020.01.27 12:40 #1624 Roman: また、mqlの文字列の下には、short[]やwchar_t[]、wchar_t*があることが多いようです。 何しろ、mqlの文字列はユニコードで、utfは2バイトですからね。 また、StringToCharArrayはshort[]からchar[]に変換する。 unicode != utf && utf != 2 bytes (utfはutfと同じではない) && MSVCは標準ではありません。 wchar_tのポイントは、サポートされているあらゆる文字を1つのwchar_tに収めることであり（まあ、smallsoftのやり方くらいですが）、入力出力ストリームは自分自身でロケールエンコーディングとの間で変換を行います。サイズ/エンコード保証はありません。dllでwchar_tを受け入れる場合、それが正しいかどうか考えてください。もちろん、砂場の向こうの大人の世界に目を向けることが面白いのであれば話は別ですが。 Roman 2020.01.27 13:45 #1625 Vict: unicode != utf && utf != 2byte (utf utf'y is different) && MSVCはリファレンスではありません。 wchar_tのポイントは、サポートされているあらゆる文字を1つのwchar_tに収めることであり（まあ、smallsoftのやり方くらいですが）、入力出力ストリームは自分自身でロケールエンコーディングとの間で変換を行います。サイズ/エンコード保証はありません。dllでwchar_tを受け入れる場合、それが正しいかどうか考えてください。もちろん、砂場の向こうの大人の世界に目を向けることが面白いのであれば話は別ですが。 そう、UnicodeとUTFは異なるエンコーディングで、本来は違うはずなのですが。 ただ、ユニコードと書いて略したかったので、うまくいかなかったのでしょう。 Unicodeのリファレンスには、この規格には世界中のほとんどすべての書き言葉の文字が含まれていると書かれていますが。 この規格は、Universal Character Set（UCS）とUnicode transformation format（UTF）の2つの主要部分から構成されています。 UnicodeにはすでにUTFエンコーディングがあるので、単語を短くするためにそのように表記したのです。 wchar_t*が正しいかどうかわからない。 Renatの例にあるものを、dllの書き方という記事から使用。 mql5の文字列はUnicodeであり，UTFを含むので，記事の例ではwchar_t*を使用するのが論理的だと思います。 サポートされているあらゆる文字を1つのwchar_tに収容すること。 サイズやエンコードの保証がないことについては、それについてさえ知りませんでしたが、それなら純度を高めるためにCish short*を使うべきでしょうか？ もちろん、MSVC IDEで正しくサポートされるのであれば、ですが。 なぜなら、いつもの「本当」が「環境」に飲み込まれて「本当」になってしまうからです。 Edgar Akhmadeev 2020.01.27 13:57 #1626 UTF-8とUTF-16は適切なビット深度を持っています。 UTF-8では、言語ページは特殊なコードで切り替わります。 UTF-16は、多種多様な文字を同時に収録しています。 Roman 2020.01.27 14:13 #1627 Edgar Akhmadeev: UTF-8とUTF-16は適切なビット深度を持っています。 UTF-8では、言語ページは特殊なコードで切り替わります。 UTF-16は、多種多様な文字を同時に収録しています。 さて、フォーラムで多くの人が書いているように、mql5の文字列はUTF-16だけだと理解しています。 そして、mqlのドキュメントには、こう書かれている。 テキストストリングは、ユニコード 形式の文字の並びで、末尾にゼロが付きます。 このため、どのエンコーディングが実際にmql5文字列なのかが分かりにくい。 また、UnicodeがすでにUTFのすべてのファミリーを含んでいるならば、なぜUTFという言葉を使い、混乱を招くのでしょうか。 ユニコードがすべて、わかりやすい。 それとも、そう言うべきでしょうか？ ビットレートがUTF-16のユニコード？ 実は以前、開発者の誰かがこう書いていました。 mqlの文字列型は、バッファ8バイトとポインタ4バイトの2つの部分からなり、結果的に12バイトになる。 削除済み 2020.01.27 14:36 #1628 Roman: UnicodeとUTFが異なるエンコーディングであることは知っています。 ちょうど、ユニコードという言葉を書いて略したかったのですが、おそらく運がなかったのでしょう。 Unicodeのリファレンスには、この規格には世界中のほとんどすべての書き言葉の文字が含まれていると書かれていますが。 この規格は、Universal Character Set（UCS）とUnicode transformation format（UTF）の2つの主要部分から構成されています。 UnicodeにはすでにUTFエンコーディングがあるので、単語を短くするためにそのように表記したのです。 wchar_t*が正しいかどうかわからない。 Renatの例にあるものを、dllの書き方という記事から使用。 mql5の文字列はUnicodeで、UTFを含んでいるので、記事の例ではwchar_t *を使用するのが論理的であると思います。 サポートされているあらゆる文字を1つのwchar_tに収容すること。 あなたは混乱しています。Unicodeは文字をコードで表した表で、以前は0〜65535（2バイト）に収まっていましたが、だんだん大きくなっていきました。そして、1文字あたり4バイトを費やすのは太っ腹です。そこで便利なのがutfという可変長のエンコーディングである（例えばutf-8はASCII文字を1バイトでエンコードする）。したがって、Unicode（テーブル）にはutfは含まれない。 サイズやエンコードの保証がないことについては、それについてさえ知りませんでしたが、それなら純度を高めるためにCish short*を使うべきでしょうか？ もちろん、MSVC IDEで正しくサポートされるのであれば、ですが。 なぜなら、いつもの「本当」が「環境」に飲み込まれて「本当」になってしまうからです。 char16_t, char32_t, 固定サイズ型が 標準である。Wchar_tは別の意味を持ちます。 Edgar Akhmadeev 2020.01.27 14:42 #1629 Roman: このフォーラムで多くの人が書いていることを理解する限りでは、mql5の文字列はUTF-16です。 そして、mqlのドキュメントには、こう書かれている。 テキストストリングは、ユニコード 形式の文字の並びで、末尾にゼロが付きます。 このため、どのエンコーディングが実際にmql5文字列なのかが分かりにくい。 そして、もしUnicodeがすでにUTFのすべてのファミリーを含んでいるならば、なぜUTFという言葉を使い、混乱を招くのでしょうか。 ユニコードがすべて、わかりやすい。 あるいは、そのように言うべきでしょうか。 UTF-16のビットレートでのユニコード？ それだけではありません。 ANSIキリル文字＝CP1251であるため ユニコードです。 UTF-8 = CP65001, // UNIX/Linux UTF-16LE = CP1200, // Windows utf-16be = cp1251。 UTF-32LE = ? UTF-32BE = ? ISO10646です。 UCS-2〜UTF-16 UCS-4 = UTF-32 混乱？いや、聞いてない。 削除済み 2020.01.27 14:42 #1630 Edgar Akhmadeev: UTF-8とUTF-16は適切なビット深度を持っています。 UTF-8では、言語ページは特殊なコードで切り替わります。 UTF-16は、多種多様な文字を同時に収録しています。 コードページって、何のこと？エンコーディングは可変長であるため、「特殊コード」は文字をエンコードするためのバイト数を定義する。UTF-8は、UTF-16と同様にあらゆるUnicode文字をエンコードすることができます。また、可変長のutf-16（サロゲートペア）。 1...156157158159160161162163164165166167168169170...247 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
いいえ、私は気づかなかったでしょう。ただし、場合によっては（Unicodeで作業する場合）可能であることを否定はしませんが。例えば、Javaではchar型は2バイトです。
私は、このJSON ライブラリを使用する方法と、char arrayを使用する方法の2つの方法で、crypto-exchangeからのデータをパースしようと試みました。
その差は、速度にして700倍（！！）にもなることが判明した。ショックでした。おそらく、最高のJSON実装とは程遠いものだったのでしょう。
文字は16LE、文字列は明らかにpascalのものです。ちなみに、Fortranからの配列も
いいえ、私は気づかなかったでしょう。ただし、場合によっては（Unicodeで作業する場合）可能であることを否定はしませんが。例えば、Javaではchar型は2バイトです。
私は、このJSON ライブラリを使用する方法と、char arrayを使用する方法の2つの方法で、crypto-exchangeからのデータをパースしようと試みました。
その差は、速度にして700倍（！！）にもなることが判明した。ショックでした。おそらく、最高のJSON実装とは程遠いものだったのでしょう。
mqlの文字列をDLLに渡すとき、DLL側ではmqlの文字列型はwchar_t*として扱われます。
また、型サイズの不一致はJavaだけでなく、アーキテクチャの種類、何だったか忘れましたが、OS、鉄にも依存します。
700回？うわー、JSONのパース用にこのライブラリ置いてたんだけど、意味ない？
また、StringToCharArrayを 変換し、ループ内で配列を解析する方が良いのでしょうか？
700回？うわー、このライブラリはJSONのパース用に置いておいただけだから意味ないのか。
また、StringToCharArrayを 変換し、ループ内で配列を解析する方が良いのでしょうか？
そう思います、はい。常にチェックする必要がありますが。測定をしてみてください。文字列の関数が最適な方法で書かれておらず、今は修正されていることを否定はしません。
1年以上前に測ったものです。
もちろん、char配列を扱う場合、コードは大きくなりますが、可能性はより柔軟になります。
また、mqlの文字列の下には、short[]やwchar_t[]、wchar_t*があることが多いようです。
何しろ、mqlの文字列はユニコードで、utfは2バイトですからね。
また、StringToCharArrayはshort[]からchar[]に変換する。
unicode != utf && utf != 2 bytes (utfはutfと同じではない) && MSVCは標準ではありません。
wchar_tのポイントは、サポートされているあらゆる文字を1つのwchar_tに収めることであり（まあ、smallsoftのやり方くらいですが）、入力出力ストリームは自分自身でロケールエンコーディングとの間で変換を行います。サイズ/エンコード保証はありません。dllでwchar_tを受け入れる場合、それが正しいかどうか考えてください。もちろん、砂場の向こうの大人の世界に目を向けることが面白いのであれば話は別ですが。
unicode != utf && utf != 2byte (utf utf'y is different) && MSVCはリファレンスではありません。
wchar_tのポイントは、サポートされているあらゆる文字を1つのwchar_tに収めることであり（まあ、smallsoftのやり方くらいですが）、入力出力ストリームは自分自身でロケールエンコーディングとの間で変換を行います。サイズ/エンコード保証はありません。dllでwchar_tを受け入れる場合、それが正しいかどうか考えてください。もちろん、砂場の向こうの大人の世界に目を向けることが面白いのであれば話は別ですが。
そう、UnicodeとUTFは異なるエンコーディングで、本来は違うはずなのですが。
ただ、ユニコードと書いて略したかったので、うまくいかなかったのでしょう。
Unicodeのリファレンスには、この規格には世界中のほとんどすべての書き言葉の文字が含まれていると書かれていますが。
この規格は、Universal Character Set（UCS）とUnicode transformation format（UTF）の2つの主要部分から構成されています。
UnicodeにはすでにUTFエンコーディングがあるので、単語を短くするためにそのように表記したのです。
wchar_t*が正しいかどうかわからない。
Renatの例にあるものを、dllの書き方という記事から使用。
mql5の文字列はUnicodeであり，UTFを含むので，記事の例ではwchar_t*を使用するのが論理的だと思います。
サポートされているあらゆる文字を1つのwchar_tに収容すること。
サイズやエンコードの保証がないことについては、それについてさえ知りませんでしたが、それなら純度を高めるためにCish short*を使うべきでしょうか？
もちろん、MSVC IDEで正しくサポートされるのであれば、ですが。
なぜなら、いつもの「本当」が「環境」に飲み込まれて「本当」になってしまうからです。
UTF-8とUTF-16は適切なビット深度を持っています。
UTF-8では、言語ページは特殊なコードで切り替わります。
UTF-16は、多種多様な文字を同時に収録しています。
UTF-8とUTF-16は適切なビット深度を持っています。
UTF-8では、言語ページは特殊なコードで切り替わります。
UTF-16は、多種多様な文字を同時に収録しています。
さて、フォーラムで多くの人が書いているように、mql5の文字列はUTF-16だけだと理解しています。
そして、mqlのドキュメントには、こう書かれている。
テキストストリングは、ユニコード 形式の文字の並びで、末尾にゼロが付きます。
このため、どのエンコーディングが実際にmql5文字列なのかが分かりにくい。
また、UnicodeがすでにUTFのすべてのファミリーを含んでいるならば、なぜUTFという言葉を使い、混乱を招くのでしょうか。
ユニコードがすべて、わかりやすい。
それとも、そう言うべきでしょうか？
ビットレートがUTF-16のユニコード？
実は以前、開発者の誰かがこう書いていました。
mqlの文字列型は、バッファ8バイトとポインタ4バイトの2つの部分からなり、結果的に12バイトになる。
UnicodeとUTFが異なるエンコーディングであることは知っています。
ちょうど、ユニコードという言葉を書いて略したかったのですが、おそらく運がなかったのでしょう。
Unicodeのリファレンスには、この規格には世界中のほとんどすべての書き言葉の文字が含まれていると書かれていますが。
この規格は、Universal Character Set（UCS）とUnicode transformation format（UTF）の2つの主要部分から構成されています。
UnicodeにはすでにUTFエンコーディングがあるので、単語を短くするためにそのように表記したのです。
wchar_t*が正しいかどうかわからない。
Renatの例にあるものを、dllの書き方という記事から使用。
mql5の文字列はUnicodeで、UTFを含んでいるので、記事の例ではwchar_t *を使用するのが論理的であると思います。
サポートされているあらゆる文字を1つのwchar_tに収容すること。
あなたは混乱しています。Unicodeは文字をコードで表した表で、以前は0〜65535（2バイト）に収まっていましたが、だんだん大きくなっていきました。そして、1文字あたり4バイトを費やすのは太っ腹です。そこで便利なのがutfという可変長のエンコーディングである（例えばutf-8はASCII文字を1バイトでエンコードする）。したがって、Unicode（テーブル）にはutfは含まれない。
サイズやエンコードの保証がないことについては、それについてさえ知りませんでしたが、それなら純度を高めるためにCish short*を使うべきでしょうか？
もちろん、MSVC IDEで正しくサポートされるのであれば、ですが。
なぜなら、いつもの「本当」が「環境」に飲み込まれて「本当」になってしまうからです。
char16_t, char32_t, 固定サイズ型が 標準である。Wchar_tは別の意味を持ちます。
このフォーラムで多くの人が書いていることを理解する限りでは、mql5の文字列はUTF-16です。
そして、mqlのドキュメントには、こう書かれている。
テキストストリングは、ユニコード 形式の文字の並びで、末尾にゼロが付きます。
このため、どのエンコーディングが実際にmql5文字列なのかが分かりにくい。
そして、もしUnicodeがすでにUTFのすべてのファミリーを含んでいるならば、なぜUTFという言葉を使い、混乱を招くのでしょうか。
ユニコードがすべて、わかりやすい。
あるいは、そのように言うべきでしょうか。
UTF-16のビットレートでのユニコード？
それだけではありません。
ANSIキリル文字＝CP1251であるため
ユニコードです。
UTF-8 = CP65001, // UNIX/Linux
UTF-16LE = CP1200, // Windows
utf-16be = cp1251。
UTF-32LE = ?
UTF-32BE = ?
ISO10646です。
UCS-2〜UTF-16
UCS-4 = UTF-32
混乱？いや、聞いてない。
UTF-8とUTF-16は適切なビット深度を持っています。
UTF-8では、言語ページは特殊なコードで切り替わります。
UTF-16は、多種多様な文字を同時に収録しています。
コードページって、何のこと？エンコーディングは可変長であるため、「特殊コード」は文字をエンコードするためのバイト数を定義する。UTF-8は、UTF-16と同様にあらゆるUnicode文字をエンコードすることができます。また、可変長のutf-16（サロゲートペア）。