mql5言語の特徴、微妙なニュアンスとテクニック - ページ 162 1...155156157158159160161162163164165166167168169...247 新しいコメント Maxim Kuznetsov 2020.01.27 00:30 #1611 Nikolai Semko: 文字列や動的配列、クラス参照を含む構造体やクラスでは、sizeof() は空に向かって指をさすことになります。 と理解することができます :-) Roman 2020.01.27 00:36 #1612 Nikolai Semko: mqlの文字列型は非常に複雑で、ドキュメントでも十分に開示されていません。 しかし、C言語から推測すると、char配列(バッファ)は文字列型にラップされています。 そして、その仕組みを理解しながら踊り始めるのです )) Nikolai Semko 2020.01.27 00:39 #1613 Roman: mqlの文字列型は非常にトリッキーで、ドキュメントでも十分に開示されていません。 しかし、C言語では文字列の型はchar配列(バッファ)であることが示唆されている そして、その仕組みを理解しながら踊り始めるのです )) C言語には文字列はありません。 Nikolai Semko 2020.01.27 00:41 #1614 Maxim Kuznetsov: 文字列や動的配列、クラス参照を含む構造体やクラスでは、sizeof() は空に向かって指をさすことになります。 と理解することができます :-) でも、なぜ? 動的配列の場合、動的配列オブジェクトのサイズが表示されます。 Roman 2020.01.27 00:43 #1615 Nikolai Semko: CにはTバックはありません。 すでにあると思いますが、そういう問題ではありません。 はい、C言語にはchar[]があり、それはmqlの文字列でラップされています。 Maxim Kuznetsov 2020.01.27 00:48 #1616 Nikolai Semko: でも、なぜ? 動的配列の場合、動的配列オブジェクトのサイズが表示されます。 誰のための、何のための、どのような大きさなのか? 52バイトは、その内部デバイスのみ。 なぜ64でないのかは不明ですが、アライメントをとったのかもしれません :-) Nikolai Semko 2020.01.27 00:52 #1617 Roman: すでにあると思いますが、そういう問題ではありません。 はい、C言語にはchar[]があり、それはmqlの文字列でラップされています。 まあ、それはわかるんですけどね。 文字列関数は 全く使っていません。早速、StringToCharArray関数でchar配列に変換して、その配列で作業しています。より効率的であることを実感しています。 特に構文解析に関しては。 Nikolai Semko 2020.01.27 00:56 #1618 Maxim Kuznetsov: 誰のための、何のための、どのような大きさなのか? 52バイトはその内部構造だけです。 なぜ64でないのかは不明ですが、整列させた可能性もありますね :-) おそらく、種類が異なる何らかの構造になっているのでしょう。例えば、5つのulongと3つのuintです。内部処理と最終アクセス時刻のために時間が存在するのかもしれない。わからない。この構造体に何が入っているかは、誰にもわからない。 Roman 2020.01.27 00:59 #1619 Nikolai Semko: まあ、それは理解できる。 文字列関数は 全く使っていません。早速、StringToCharArray関数でchar配列に変換して、その配列で作業しています。より効率的であることを実感しています。 ほとんどの場合、mqlの文字列はshort[]またはwchar_t[]またはwchar_t*です。 何しろ、mqlの文字列はユニコードで、utfは2バイトですからね。 また、StringToCharArrayはshort[]からchar[]に変換する。 Nikolai Semko 2020.01.27 01:08 #1620 Roman: そして、ほとんどの場合、mqlの文字列の下にshort[]があります。 結局、mqlのUnicodeでは、文字列は2バイトです。 また、StringToCharArrayは、short[]からchar[]に変換します。 いいえ、私は気づかなかったでしょう。場合によっては(Unicodeで作業する場合)可能であることを否定はしませんが。例えば、Javaではchar型は2バイトです。 私は、このJSON ライブラリを使用する方法と、char arrayを使用する方法の2つの方法で、crypto-exchangeからのデータをパースしようと試みました。 その差は、速度にして700倍(!!)にもなることが判明した。ショックでした。おそらく、最高のJSON実装とは程遠いものだったのでしょう。 1...155156157158159160161162163164165166167168169...247 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
文字列や動的配列、クラス参照を含む構造体やクラスでは、sizeof() は空に向かって指をさすことになります。
と理解することができます :-)
mqlの文字列型は非常に複雑で、ドキュメントでも十分に開示されていません。
しかし、C言語から推測すると、char配列(バッファ)は文字列型にラップされています。
そして、その仕組みを理解しながら踊り始めるのです ))
mqlの文字列型は非常にトリッキーで、ドキュメントでも十分に開示されていません。
しかし、C言語では文字列の型はchar配列(バッファ)であることが示唆されている
そして、その仕組みを理解しながら踊り始めるのです ))
C言語には文字列はありません。
文字列や動的配列、クラス参照を含む構造体やクラスでは、sizeof() は空に向かって指をさすことになります。
と理解することができます :-)
でも、なぜ?
動的配列の場合、動的配列オブジェクトのサイズが表示されます。
CにはTバックはありません。
すでにあると思いますが、そういう問題ではありません。
はい、C言語にはchar[]があり、それはmqlの文字列でラップされています。
でも、なぜ?
動的配列の場合、動的配列オブジェクトのサイズが表示されます。
誰のための、何のための、どのような大きさなのか?
52バイトは、その内部デバイスのみ。
なぜ64でないのかは不明ですが、アライメントをとったのかもしれません :-)
すでにあると思いますが、そういう問題ではありません。
はい、C言語にはchar[]があり、それはmqlの文字列でラップされています。
まあ、それはわかるんですけどね。
文字列関数は 全く使っていません。早速、StringToCharArray関数でchar配列に変換して、その配列で作業しています。より効率的であることを実感しています。
特に構文解析に関しては。
誰のための、何のための、どのような大きさなのか?
52バイトはその内部構造だけです。
なぜ64でないのかは不明ですが、整列させた可能性もありますね :-)
おそらく、種類が異なる何らかの構造になっているのでしょう。例えば、5つのulongと3つのuintです。内部処理と最終アクセス時刻のために時間が存在するのかもしれない。わからない。この構造体に何が入っているかは、誰にもわからない。
まあ、それは理解できる。
文字列関数は 全く使っていません。早速、StringToCharArray関数でchar配列に変換して、その配列で作業しています。より効率的であることを実感しています。
ほとんどの場合、mqlの文字列はshort[]またはwchar_t[]またはwchar_t*です。
何しろ、mqlの文字列はユニコードで、utfは2バイトですからね。
また、StringToCharArrayはshort[]からchar[]に変換する。
そして、ほとんどの場合、mqlの文字列の下にshort[]があります。
結局、mqlのUnicodeでは、文字列は2バイトです。
また、StringToCharArrayは、short[]からchar[]に変換します。
いいえ、私は気づかなかったでしょう。場合によっては(Unicodeで作業する場合)可能であることを否定はしませんが。例えば、Javaではchar型は2バイトです。
私は、このJSON ライブラリを使用する方法と、char arrayを使用する方法の2つの方法で、crypto-exchangeからのデータをパースしようと試みました。
その差は、速度にして700倍(!!)にもなることが判明した。ショックでした。おそらく、最高のJSON実装とは程遠いものだったのでしょう。