Errors, bugs, questions - page 1409
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Regarding the announcement of the new build 1200.
Such solutions look very crusty whenlong time_msc is added to the structure along withdatetimetime. The question is why time is needed then? It is a senseless waste of resources.
The same is true for uint flags whileuchar would be enough there or at least ushort (that with a significant reserve for the future). And why uint is needed there is beyond comprehension.The sad thing is that the developers have completely stopped thinking about rational data storage. An array of ticks is a colossal size by itself. And here memory is being squandered so carelessly...
Anyway, speaking of time. Maybe it's time to introduce into MQL a normal time type that would contain milliseconds, or else we'll just have these crutches.The more so because datetime itself in its present form is a very irrational thing: it consumes 8 bytes but contains only seconds - and who needs it? 4 bytes(uint) are enough for this task for the next 90 years (and Duncan McLeod is not among us).
This solution preserves compatibility with older programs that use time in seconds or SymbolInfoTick().
Believe our experience, the "let's make it in a byte or two" game leads to monstrous problems in the future. You understand it only when you write software for 10 years ahead.
The 4 bytes of datetime in seconds will end in 2038 (22 more years), not in 90 years.
What does TM=30M mean here?
In our experience, the "let's make it a byte or two" game leads to horrendous problems in the future. You only realise this when you write software 10 years in advance.
So it's not a question of making it to the tightest. Of course, we should leave some margin for the future, but within reasonable limits. For instance, in the case we're discussing, the flags field stores information about six other fields only. If you make it of ushort type, you will have 10 more fields to spare. How much farther can you add to it?
If you plan to save a full glass, for example, 32 bits are not enough. Why not make it 64 bits at once? Although, obviously, for a glass you will need very different structure.
Of course, I understand that an extra 2 bytes is not very significant. But it turns out that 2 bytes here, 2 bytes there... ...and it adds up to a lot.
4 datetime bytes in seconds end in 2038 (another 22 years), not in 90 years.
I tell you - you will suffer with non-extensible economical structures, start thinking in terms of decades, necessity of long support and everything will become clear.
With 4 byte datetime masses of software will have big problems with overflows just in 2038, which will lead to frantic rewriting of old code. And overflows will be caught even earlier on mat operations and deltas.
I've been programming for 25 years and I know what I'm talking about. I've been writing cost-effective programs all my life. Look at our terminals - they are real masterpieces by the amount of functionality contained in small-sized single exe files. Run a single naked terminal.exe on a clean computer and see what happens.
But things have changed now - either you write 64-bit code with a margin almost everywhere or get left out of the future. This is especially important for us, since we are not releasing closed boxes, but development platforms with a compatibility requirement.
We'll be kicking ourselves in a couple of years because we'll find ourselves underinvested again. And all around are computers with dozens of gigabytes in basic equipment.
What does TM=30M mean here?
With 4 byte datetime most software will have great problems with overflows just in 2038 what will lead to frantic rewriting of the old code. And overflows will be caught even earlier on mat operations and deltas.
You mean MQL4 codes? (where datetime was originally based on int). Then, of course, another conversation related to compatibility problems. But I was originally talking about rationality. So, in this case, rationality suffers.
However, in any case, I think you will agree that a new type of time containing milliseconds is needed and it should not start from 1970, but much earlier, for example from 1900. It's not just about forex any more. Exchanges have been around for a very long time.
...
However, in any case, I think you will agree that a new type of time is needed, one that contains milliseconds. And it should not start in 1970, but much earlier, for example in 1900. We are not just talking about forex now, but exchanges have been around for a very long time.
The only problem is that it was not fashionable to use computers under Tsar Gorokh and the history of ticks was not preserved for future generations...
It's not necessarily about ticks. For example, the day candles are still intact.
I'm embarrassed to ask, why do you need the prices of the daily candlesticks for 1900... years? To do technical analysis? To test the Advisors on the history?
The speed of execution will increase from 2 to 10 times for x64 versions of MetaTrader 5 terminal.
The result is well worth it. Although we will still work on the compilation speed.
You've recently boasted that the speed of MQL is close to C++. And now it turns out that you will outrun C++ by several times? ))
If you manage to get this speed at some specially prepared tests, it doesn't mean that you will get it at other cases as well. But the compilation speed is slowing down in all the cases.