Mt4 End of support. - page 29
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
The main disadvantage: OOP forces you to go down the path of fragmenting code into many functions.
It's easier for humans to accept fragmented code, but fragmentation is contraindicated to any mechanism.
All right, but what's the disadvantage?
It is the main advantage ! Precisely because it is easier for a person to perceive fragmented code !
The computer has to adapt to the human, not the human to the computer.
That's right, but what's the downside?
That's the main advantage ! Precisely because it's easier for a person to perceive fragmented code !
The computer should adapt to the human, not the human to the computer.
Alas, a developer should think about efficiency of his mechanism first of all, not about his comfort)).
Otherwise the mechanism will "limp".
The developer should adjust to the computer.
If the quotes come from the same server, it makes no difference which instrument. After all, bars are opened simultaneously on each instrument.
It is different if the sources of quotations are in different parts of the world. For minutes it does not matter, but there may be a problem with higher timeframes. Perhaps the time functions need to be studied in more detail and accurate time correction needs to be done. But that's the next stage in the development of this solution...
You need to make a calibration for this function...
At first I wanted to read everything that was written without me, in case there was already a question and answer, but I'm afraid it will be difficult to find the post that needs to be quoted later.
For now there is only 1 question: As everyone knows, a new bar will not appear until the first tick in the new time interval. Therefore, if there should be a bar by milliseconds but it is absent, you can get indicator readings from the wrong bar.
I hope to find an answer to the second question, it was asked by Artem.
At first I wanted to read everything that was written without me, in case there was already a question and answer, but I'm afraid it will be difficult to find the post that needs to be quoted.
So far only 1 question: As everyone knows, a new bar will not appear until the first tick in the new time interval. Therefore, if there should be a bar by milliseconds but it is absent, we can get indicator values from the wrong bar.
I hope to find an answer to the second question, it was asked by Artem.
Yes, we discussed this yesterday.
I used to deal with another platform and there bars were formed by time regardless of quotes arrival (look at TWS).
I was told that is not the case with MT.
I will add a quote arrival check to confirm the event of new bar appearance.
I have already replied that bars open regardless of the arrival of a quote. If there is no quote, the price of the new bar will be the closing price of the previous bar. The fact of a new bar will be fixed regardless of the arrival of quotes, by the counters themselves, which run on a timer.
The specific timeframe does not matter, because it is just a counter that reaches its value and sets the event of the new bar of that timeframe. This is simply a method of synchronising with the appearance of new bars of different timeframes. SYNCHRONIZATION.
The instrument does not matter either. If the quotes are from one server, it means that they have the same time of new bars appearance. Therefore, it does not matter which instrument, as long as these instruments are from one point of the globe.
I'll finish what I said and do other things. A little bit of good stuff).
And how can one explain the fact that Friday's close, the previous bar of any period equals 1.20333, and Monday's open of any period equals 1.20142?
Of course this is one broker's quote, the other might be a little different, but there is a difference in all of them.
And how do you explain the fact that Friday's close, the previous bar of any period is 1.20333 and Monday's open of any period is also 1.20142?
This is of course the quotes of one broker, the other may be a bit different, but they all have differences.
It is explained by the gap. It happens at the opening of the session.
I am not an expert in trading, so do not judge my opinion too harshly).
And I know even less about what happens on the forex market.)
Alas, the designer must think of the efficiency of his mechanism first, not his comfort.)
Otherwise the mechanism will "limp".
The developer has to adjust to the computer.
No.
Let the computer adjust to me. I have enough other problems. The developer can only tweak where the computer cannot handle the task, say, in bottlenecks where it lacks performance or memory. Then, yes, it's the developer's turn to adjust. But so far I haven't come across any places where OOP would impose such a significant additional load on the computer that it would have to be somehow reduced.
Something like that (code for MQL5):
But I repeat - I am an OOP supporter.
It's just a really unfortunate example to show what is impossible to do in procedural programming.
When I started this, I didn't intend to show that anything is possible/impossible to do, but just more convenient to use in the future when writing my own codes.
But it turned out, as V.S. said, I wanted the best, but it turned out as always.
Oh, no.
It's the computer that adjusts to me. I have enough other problems. The developer can only adjust where the computer "can't handle", say, in "bottlenecks", where there is not enough performance or memory. Then, yes, it's the developer's turn to adjust. But so far I haven't come across any places where OOP provides such a significant additional load on the computer that it must be somehow reduced.
The load on the computer is caused by developer's careless attitude to the issue of coherence of his mechanism. A desire to save energy to improve the system. An unreasonable waste of computer resources in the name of easing their work.
As long as the computer successfully copes with inefficiently written code, the developer will continue to "parasitize" on the processing power. This is a dead-end road.
Sooner or later, the ineffective mechanism will stop developing and be replaced by a better counterpart.
Man's time and effort will be wasted and his brainchild will end up in the dustbin.
In the competitive world, this risk exists all the time.
When we design machines, we should think about their performance first, and about the comfort and convenience of spending our working hours second.)
The burden is placed on the computer by the developer's negligent attitude towards the coherence of their mechanism. A desire to save energy on improving the system. Unreasonable consumption of computer resources in the name of making their work easier.
As long as the computer successfully copes with inefficiently written code, the developer will continue to "parasitize" on the processing power. This is a dead-end road.
Sooner or later, the ineffective mechanism will stop developing and be replaced by a better counterpart.
Man's time and effort will be wasted and his brainchild will end up in the dustbin.
In the competitive world, this risk exists all the time.
When designing mechanisms, we must think about their performance in the first place, and about comfort and convenience of our working hours in the second).
It is called writing the program. That's why a properly working (and readable by any other developer) code is written first and only then it is optimized - if there is anything to optimize there at all.