structMqlRates
{
datetime time; // время начала периодаdouble Base; // базовая цена бара. Все остальные цены отсчитываются от базы в пипсах short openBid; // цена открытия Bidshort highBid; // наивысшая цена за период Bidshort lowBid; // наименьшая цена за период Bidshort closeBid // цена закрытия Bidshort openAsk; // цена открытия Askshort highAsk; // наивысшая цена за период Askshort lowAsk; // наименьшая цена за период Askshort closeAsk // цена закрытия Asklong tick_volume; // тиковый объемlong real_volume; // биржевой объем
};
你能诚实地回答使用OHLC Bid + Spread，与OHLC Bid + OHLC Ask的原因是什么？存储8个数字而不是5个（条形和历史格式很难改变）？它是否会对提供的历史数量产生重大影响？或者，也许你只是没有问价记录？测试员的逻辑是否变得更加复杂？那么，在第二种情况下，就更简单了--根本就没有传播的概念。是什么阻止了它，要诚实。
条形结构的大小 是最重要的特征，它按比例影响着终端所消耗的资源量。
我们始终面临着节约资源的任务，所以以这种形式进行扩张是不合适的。
MqlRates 的大小。
等于（如果我没有弄错的话）46个字节。
替代结构的大小。
等于76个字节。
也就是说，在最坏的情况下，我们谈论的是在历史下载期间流量增加65%，以及终端和测试人员（包括代理）的内存消耗。显然，只是一些65%的人不能阻止你。原因显然是不同的。
如果你不相信你的对手的话，那么说话还有什么意义？
MqlRates 的大小。
等于（如果我没有弄错的话）46个字节。
替代结构的大小。
等于76个字节。
也就是说，我们谈论的是在最坏的情况下，终端和测试人员（包括代理）在历史下载和内存消耗期间的流量增加65%。显然，只是一些65%的人不能阻止你。原因显然是不同的。
我得到了48个字节。
谁说做空是不够的--让他成为第一个向我抛出至少一个例子的人（无论如何，来自证券交易所或外汇）。条形结构的大小 是最重要的特征，它按比例影响着终端所消耗的资源量。
我们始终面临着节约资源的任务，所以这种形式的延期是不合适的。
Renat，是否有任何尝试来优化MqlRates 的结构？例如，如果现在的精度限制在小数点后五位，为什么我们还需要OLHC的双倍（8字节）精度值？为什么不把这些值存储为归一化的3位或5位int，这样占用一半的内存？
用这种方法可以写出的最大数值是 42949.67295。
是否有任何OLHC的外汇数据会超过这个限制？
是否有OLHC的外汇数据会超出这个界限？
我得到了48个字节。
谁说做空是不够的--让他成为第一个向我抛出至少一个例子的人（无论如何，来自证券交易所或外汇）。也就是说，我们谈论的是在最坏的情况下，终端和测试者（包括代理）下载历史和内存消耗的流量增加了65%。
Vladix:
例如，如果.....................，为什么OLHC值需要双倍（8字节）的精度？
这是顺便说一下，是的。
很有可能被以下内容取代而且没有人受到影响。然后大小神奇地恢复到46字节。）
我得到了48个字节。
谁说做空是不够的--让他成为第一个向我抛出至少一个例子的人（无论如何，来自证券交易所或外汇）。