新的MQL4语法 - 页 3 123456 新评论 Ian Venner 2014.01.25 18:50 #21 我有一个关于变量类型的问题，int、uint、char、short ushort等。新的编译器对由于类型转换而可能造成的数据损失提出了警告，所以最好的做法是。 a) 使用最适合变量要求的类型，或者。 b) 避免类型之间的转换，因此一切都使用int。(嗯，所有不需要浮点的东西) Simon Gniadkowski 2014.01.25 18:59 #22 SDC: 我有一个关于变量类型的问题，int, uint, char, short ushort等，最好的做法是。 a) 使用最适合该变量要求的类型，或者 b) 避免在不同类型之间进行转换，因此一切都使用int。(嗯，所有不需要浮点的东西) 如果你需要一个无符号的长字符串，一个int是不行的......使用正确的类型和明确的类型转换。 IMO Ian Venner 2014.01.25 19:02 #23 你所说的显式类型转换是指在不同类型之间进行计算之前进行转换？ Alain Verleyen 2014.01.25 19:13 #24 RaptorUK: 如果你需要一个无符号的长字符串，一个int是不行的......使用正确的类型和明确的类型转换。 IMO 同意。 Alain Verleyen 2014.01.25 19:15 #25 SDC: 你所说的显式类型转换是指在不同类型之间进行计算之前进行转换？ 请看这里：https://www.mql5.com/en/docs/basis/types/casting Ian Venner 2014.01.25 19:19 #26 好文章，谢谢angevoyageur，我下班回家后会好好读一下。 Simon Gniadkowski 2014.01.25 21:04 #27 SDC: 你说的明确的类型转换是指在不同类型之间的任何计算之前进行转换？ 不，我的意思是你可以像这样将一个 ulong 转换为一个 int . . ulong VariableUlong; int VariableInt; VariableUlong = 100; VariableInt = (int) VariableUlong; // explicit typecasting . . . Ian Venner 2014.01.26 03:34 #28 好的，是的，我想你就是这个意思。 除了我不是真的在问ulong的问题。我很少需要处理这么大的数值，因为32位整数无法容纳。我甚至不知道如何说一个64位的整数可以容纳的数字，笑...... 我可能应该说得更具体一些，我今天早上没有时间把我的问题写清楚，但现在我回家了，我会写的。 在老的mql4中，我们用整数来表示一切。我们会写for(int i=0; i<100; i++) 我们不需要负值，我们也不需要比100更大的值，所以我们可以用Uchar来表示。这是否意味着我们应该这样做？ 当我看其他程序员的代码时，他们中的很多人似乎都在使用32位整数类型。这有什么合理的理由吗？他们知道什么，而我还没有发现？在整个程序中使用最小尺寸的变量类型是否会造成令人头痛的类型转换问题，而不是因为文件尺寸稍小？还是说它能节省大量的内存？是否可以认为，只要一种类型的值可以被另一种类型所容纳，就可以这样做？不同类型之间的类型转换是否比使用同一类型要多用很多CPU？ 更新：我一直在研究这个问题，我在stackoverflow.com 上 看到了对一个类似问题 的答复 "从性能上讲，int几乎在所有情况下都更快。CPU的设计是为了有效地处理32位数值。 较短的值处理起来很复杂。比如说，要读一个字节，CPU必须读取包含它的32位块，然后屏蔽掉上面的24位。 要写一个字节，它必须读取目标32位块，用所需的字节值覆盖低8位，然后再写回整个32位块。 当然，从空间上来说，你可以通过使用较小的数据类型来节省一些字节。所以，如果你要建立一个有几百万行的表，那么较短的数据类型可能值得考虑。(同样可能是你应该在你的数据库中使用更小的数据类型的很好的理由) 而且从正确性上讲，一个int不容易溢出。如果你认为你的值将适合于一个字节，然后在未来的某个时刻，代码的一些看起来无害的变化意味着更大的值被存储到其中，怎么办？ 这些就是为什么int应该是所有积分数据的默认数据类型的一些原因。只有在你真正想存储机器字节的时候才使用字节。只有在你处理文件格式或协议或类似的实际指定16位整数值的情况下才使用shorts。如果你只是和一般的整数打交道，就把它们变成ints。" Simon Gniadkowski 2014.01.26 11:14 #29 SDC:好的，是的，我想你就是这个意思。除了我不是真的在问ulong的问题。我很少需要处理这么大的数值，因为32位整数无法容纳。我甚至不知道如何说一个64位的整数可以容纳的数字，笑......我可能应该说得更具体一些，我今天早上没有时间把我的问题写清楚，但现在我回家了，我会写的。在老的mql4中，我们用整数来表示一切。我们会写for(int i=0; i<100; i++) 我们不需要负值，我们也不需要比100更大的值，所以我们可以用Uchar来表示。这是否意味着我们应该这样做？uchar - 无符号字符，你为什么要用它来做一个循环呢，对我来说没有意义。你将与ulongs一起工作，这就是一个新的datetime ......当你没有考虑到将来的类型转换时，你将得到警告 ......处理这个警告或忽略它。不要只寄希望于最好的结果，就像你现在所做的那样，学习和理解。 你从stackoverflow 上发布的东西对我来说是有意义的，我认为这是很好的建议。 William Roeder 2014.01.26 13:43 #30 SDC: 不同类型之间的类型转换是否比使用同一类型要多用很多CPU？ 在不同的尺寸之间使用更多的CPU，不是多得多。只是在修改结构中的char时，像提到的32位的fetch, isolate, operate, place, write等不同指令。就像乘以0.5比除以2.0使用的CPU略少一样。 每一个数组元素 保存16位在GB机器上是没有意义的，当我在8KB（原文如此）中实现应用程序、数据库、GUI（vt100）时，我就是这么做的。在128位平台普及之前，每一个（对所有东西）64位是没有意义的。 有符号与无符号没有什么区别。这只是一个赋值，没有改变位。区别在于使用该变量的代码。例如，A[index]做 Address(a) + index * sizeof(a[0])，其中加号是有符号或无符号加法。 为了编码清晰，我会使用uint来索引数组，因为A[-1]没有意义，但这样向下计数就有问题了 FOR(uint iA=n; iA >= 0; iA--){} iA>=0总是真的。 使用int（或uint），除非你因为其他原因必须使用。 123456 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我有一个关于变量类型的问题，int、uint、char、short ushort等。新的编译器对由于类型转换而可能造成的数据损失提出了警告，所以最好的做法是。
a) 使用最适合变量要求的类型，或者。
b) 避免类型之间的转换，因此一切都使用int。(嗯，所有不需要浮点的东西)
我有一个关于变量类型的问题，int, uint, char, short ushort等，最好的做法是。
a) 使用最适合该变量要求的类型，或者
b) 避免在不同类型之间进行转换，因此一切都使用int。(嗯，所有不需要浮点的东西)
你所说的显式类型转换是指在不同类型之间进行计算之前进行转换？
如果你需要一个无符号的长字符串，一个int是不行的......使用正确的类型和明确的类型转换。 IMO
你所说的显式类型转换是指在不同类型之间进行计算之前进行转换？
好文章，谢谢angevoyageur，我下班回家后会好好读一下。
你说的明确的类型转换是指在不同类型之间的任何计算之前进行转换？
不，我的意思是你可以像这样将一个 ulong 转换为一个 int . .
好的，是的，我想你就是这个意思。
除了我不是真的在问ulong的问题。我很少需要处理这么大的数值，因为32位整数无法容纳。我甚至不知道如何说一个64位的整数可以容纳的数字，笑......
我可能应该说得更具体一些，我今天早上没有时间把我的问题写清楚，但现在我回家了，我会写的。
在老的mql4中，我们用整数来表示一切。我们会写for(int i=0; i<100; i++) 我们不需要负值，我们也不需要比100更大的值，所以我们可以用Uchar来表示。这是否意味着我们应该这样做？
当我看其他程序员的代码时，他们中的很多人似乎都在使用32位整数类型。这有什么合理的理由吗？他们知道什么，而我还没有发现？在整个程序中使用最小尺寸的变量类型是否会造成令人头痛的类型转换问题，而不是因为文件尺寸稍小？还是说它能节省大量的内存？是否可以认为，只要一种类型的值可以被另一种类型所容纳，就可以这样做？不同类型之间的类型转换是否比使用同一类型要多用很多CPU？
更新：我一直在研究这个问题，我在stackoverflow.com 上 看到了对一个类似问题 的答复
"从性能上讲，int几乎在所有情况下都更快。CPU的设计是为了有效地处理32位数值。
较短的值处理起来很复杂。比如说，要读一个字节，CPU必须读取包含它的32位块，然后屏蔽掉上面的24位。
要写一个字节，它必须读取目标32位块，用所需的字节值覆盖低8位，然后再写回整个32位块。
当然，从空间上来说，你可以通过使用较小的数据类型来节省一些字节。所以，如果你要建立一个有几百万行的表，那么较短的数据类型可能值得考虑。(同样可能是你应该在你的数据库中使用更小的数据类型的很好的理由)
而且从正确性上讲，一个int不容易溢出。如果你认为你的值将适合于一个字节，然后在未来的某个时刻，代码的一些看起来无害的变化意味着更大的值被存储到其中，怎么办？
这些就是为什么int应该是所有积分数据的默认数据类型的一些原因。只有在你真正想存储机器字节的时候才使用字节。只有在你处理文件格式或协议或类似的实际指定16位整数值的情况下才使用shorts。如果你只是和一般的整数打交道，就把它们变成ints。"
好的，是的，我想你就是这个意思。
除了我不是真的在问ulong的问题。我很少需要处理这么大的数值，因为32位整数无法容纳。我甚至不知道如何说一个64位的整数可以容纳的数字，笑......
我可能应该说得更具体一些，我今天早上没有时间把我的问题写清楚，但现在我回家了，我会写的。
在老的mql4中，我们用整数来表示一切。我们会写for(int i=0; i<100; i++) 我们不需要负值，我们也不需要比100更大的值，所以我们可以用Uchar来表示。这是否意味着我们应该这样做？
uchar - 无符号字符，你为什么要用它来做一个循环呢，对我来说没有意义。你将与ulongs一起工作，这就是一个新的datetime ......当你没有考虑到将来的类型转换时，你将得到警告 ......处理这个警告或忽略它。不要只寄希望于最好的结果，就像你现在所做的那样，学习和理解。
你从stackoverflow 上发布的东西对我来说是有意义的，我认为这是很好的建议。
在不同的尺寸之间使用更多的CPU，不是多得多。只是在修改结构中的char时，像提到的32位的fetch, isolate, operate, place, write等不同指令。就像乘以0.5比除以2.0使用的CPU略少一样。
每一个数组元素 保存16位在GB机器上是没有意义的，当我在8KB（原文如此）中实现应用程序、数据库、GUI（vt100）时，我就是这么做的。在128位平台普及之前，每一个（对所有东西）64位是没有意义的。
有符号与无符号没有什么区别。这只是一个赋值，没有改变位。区别在于使用该变量的代码。例如，A[index]做 Address(a) + index * sizeof(a[0])，其中加号是有符号或无符号加法。为了编码清晰，我会使用uint来索引数组，因为A[-1]没有意义，但这样向下计数就有问题了 FOR(uint iA=n; iA >= 0; iA--){} iA>=0总是真的。
使用int（或uint），除非你因为其他原因必须使用。