MQL4の新しい構文 - ページ 3

新しいコメント
 

int, uint, char, short ushort などの変数の型について質問があります。新しいコンパイラは、型変換によるデータ損失の可能性について警告を出しますが、これはベストプラクティスでしょうか。

a) 変数の要件に最も適したものを使用する、または。

b) 型の変換を避けるため、全てにintを使う。(まあ、浮動小数点が必要ないものは全てですが)

 
SDC:

int, uint, char, short ushort などの変数の型について質問があります。

a) 変数の要件に最も適したものを使用する。

b) 変数型間の変換を避け、全てにintを使用する。(まあ、浮動小数点が必要ないものはすべてですが)

符号なし long が必要な場合は，int では不十分です． 正しい型と明示的な型変換を使用してください． IMO
 

明示的な型変換とは、異なる型間の計算を行う前に変換を行うという意味ですか？

 
RaptorUK:
もし、符号なし長文が必要なら、intでは不十分です。正しい型と明示的な型変換を使用してください。 IMO

同意します。
 
SDC:

明示的な型変換とは、異なる型間の計算を行う前に変換を行うという意味ですか？

こちらをご覧ください :https://www.mql5.com/en/docs/basis/types/casting
 

良い記事ですありがとうございますangevoyageur 仕事から帰ったらちゃんと読みます。

 
SDC:

明示的な型変換とは、異なる型間の計算を行う前に変換を行うという意味ですか？

そうではなく、ulongをintに変換するには、次のようにします。

ulong VariableUlong;

int VariableInt;

VariableUlong = 100;

VariableInt = (int) VariableUlong;   // explicit typecasting . . .  
 

OK......そう、そういうことですね。

ただし、私はulongについて本当に尋ねたわけではありません。32ビット整数では対応できないような大きな値を扱うことはほとんどないでしょう。64ビット整数が保持できる数をどう言えばいいのかさえわかりません(笑)。

今朝は時間がなくて質問をきちんと書けなかったのですが、家に帰ってから書きます。

昔のmql4では全てに整数を使用していました。for(int i=0; i<100; i++) 負の値は必要ないし、100より大きな値も必要ないので、ucharを使うことができました。ということでしょうか？

他のプログラマーのコードを見ると、多くの人が一様に32ビットの整数型を使っているようです。これには何か正当な理由があるのでしょうか？私がまだ知らないことを、彼らは知っているのでしょうか？プログラム全体で最も小さなフットプリントの変数型を使用することは、ファイルサイズをわずかに小さくすること以外に理由がないのに、タイプキャストの問題で頭を悩ませることになるのでしょうか？それとも、多くのRAMを節約できるのでしょうか？ある型の値が他の型に対応できる限り、それを行っても問題ないと考えてよいのでしょうか？異なる型間でのタイプキャストは、同じ型を使用するよりも多くのCPUを使用するのでしょうか？

更新：この件について調べていたら、stackoverflow.comで同じような質問に対する 次のような返答を読みました。

「性能的には、ほとんどすべてのケースでint型が高速です。CPUは32ビットの値で効率的に動作するように設計されています。

短い値は扱いが複雑です。例えば1バイトを読むには、CPUはそれを含む32ビットブロックを読み、上位24ビットをマスクしなければなりません。

一方、1バイトを書き込むには、書き込む先の32ビットブロックを読み、下位8ビットを書き込む値で上書きした後、再び32ビットブロック全体を書き込む必要がある。

もちろん、スペース的には、より小さなデータ型を使用すれば、数バイトの節約になります。したがって、数百万行のテーブルを構築する場合、より短いデータ型を検討する価値があるかもしれません。(同じことが、データベースでより小さいデータ型を使うべき理由にもなるかもしれません）。

また、正しさの面でも、int型は簡単にオーバーフローしない。もし、あなたの値が1バイトに収まると思っていたら、将来のある時点でコードに無害そうな変更が加えられて、より大きな値が格納されるようになったらどうでしょう？

このような理由から、int型はすべての積分データのデフォルトデータ型として使用されるべきなのです。byteはマシンバイトを格納する場合のみ使用します。ファイルフォーマットやプロトコルなど、実際に16ビットの整数値を指定するものを扱う場合のみ、shortsを使用します。一般的に整数を扱うのであれば、int型にしてください。"

 
SDC:

OK......そう、そういうことですね。

ただし、私はulongについて本当に尋ねたわけではありません。32ビット整数では対応できないような大きな値を扱うことはほとんどないでしょう。64ビット整数が保持できる数をどう言えばいいのかさえわかりません(笑)。

今朝は時間がなくて質問をきちんと書けなかったのですが、家に帰ってから書きます。

昔のmql4では全てに整数を使用していました。for(int i=0; i<100; i++) 負の値は必要ないし、100より大きな値も必要ないので、ucharを使うことができました。ということは、こうすればいいのでしょうか？

uchar - 符号なし文字、なぜこれをループに使うのですか？ 私には意味がわかりません。あなたはulongsを扱うことになります、それは新しいdatetimeがそうです ... そして、あなたが将来それについて考えずにタイプキャストしたとき、あなたは警告を受けるでしょう ... 警告に対処するか、それを無視する。しかし、ただベストを望むだけでなく、あなたが今しているように、学び、理解することです。

あなたがstackoverflowから 投稿したものは、私には意味があります、私はそれが良いアドバイスだと思います。

 
SDC: 異なる型間のタイプキャストは、同じ型を使用するよりも多くのCPUを使用するのでしょうか？

異なるサイズ間では、より多くのCPUを使いますが、それほど多くではありません。ただ、構造体内のcharを変更する際に、32bitのフェッチ、アイソレート、オペレーション、プレイス、ライトのような命令が異なるだけです。0.5倍するのと2.0倍するのとでは、CPUの消費量が若干違うのと同じです。

配列の要素 ごとに16ビット保存するのはGB機では意味がありません。私はアプリケーション、データベース、GUI（vt100）を8KBで実装したときにそうしました（中略）（すべてにおいて）64ビットにするのは128ビットプラットフォームが一般的になるまで意味がありません。

符号付きと符号無しの違いはありません。単なる代入であり、ビットは変更されていません。違いは、その変数を使用するコードです。例えば、A[index] は Address(a) + index * sizeof(a[0]) で、プラスは符号付きか符号なしの足し算です。

A[-1]は意味がないので、コーディングを明確にするために、配列のインデックスにはuintを使いますが、カウントダウンが問題になります FOR(uint iA=n; iA >= 0; iA--){} iA>=0 は常に真です。

他の理由でどうしても必要な場合を除き、int（またはuint）を使用します。
123456
新しいコメント