![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
1.Made some include classes based on the article. Just don't understand why to use classes instead of just making a include file with callable functions?
2.I have a question, to improve optimization speed, is it better to split the include files into several or put everything in one?
3. I have a feeling that if I call the indicator in a include file, rather than in an Expert Advisor, the optimization speed is faster...?
1.Made some include classes based on the article. Just don't understand why to use classes instead of just making a include file with callable functions?
2.I have a question, to improve optimization speed is it better to split the include files into several or put everything in one?
3.I have a feeling that if I call the indicator in a include file, rather than in an EA, the optimization speed is faster...?
1. Classes will be needed when polymorphism is needed, i.e. calls of different functions with similar purpose. The simplest example is when a block receives a pointer to an order and we need to get its ticket. Taking into account real and historical orders, as well as MT4 and MT5 - we get four different functions to work with.
In case of procedural approach - we need to have a certain switch that will call the necessary function depending on the order type. In case of OOP - we just call the function to get the ticket. The necessary function will be called automatically. However, in the case of OOP - we need the preliminary work to define the hierarchy of classes and functions.
2. The optimization is carried out according to the ready executable module. Therefore it does not matter whether the source code is divided into files or crammed into one big file. The division into files is solely the choice of the programmer, as it is convenient to him.
3. There is absolutely no difference. Personally, I never call any indicators, preferring to calculate their values directly within an Expert Advisor.
1. Classes will be needed when polymorphism - i.e. calling different functions with similar purpose - is needed. The simplest example - a block receives a pointer to an order, we need to get its ticket. Taking into account real and historical orders, as well as MT4 and MT5 - we get four different functions to work with.
In case of procedural approach - we need to have a certain switch that will call the necessary function depending on the order type. In case of OOP - we just call the function to get the ticket. The necessary function will be called automatically. However, in the case of OOP - we need the preliminary work to define the hierarchy of classes and functions.
2. The optimization is carried out according to the ready executable module. Therefore it does not matter whether the source code is divided into files or crammed into one big file. Breaking it up into files is entirely the choice of the programmer to do it himself.
3. There is absolutely no difference at all. I personally never call any indicators, preferring to calculate their values directly inside an Expert Advisor.
I see. Thank you. Of course, it all comes in handy because we can wrap a lot of code in files and classes and leave only a couple of lines in the Expert Advisor.
Separately, it's easier to check code fragments for errors, add something new, etc. The code becomes easier to understand, especially for µl5.
It is only unclear why so many local gardeners have become convinced excavators and make a pit in their own plot under a tree.)
They must have decided to build a house on their plot as well. What's wrong with that?
Yes, of course, even many of the big canals that mankind now enjoys are dug with a shovel. But back then, there were simply no excavators. So why dig a pit with a shovel now that there are excavators?
They must have decided to build a house on their plot as well. What's wrong with that?
Yes, of course, even many of the big canals that humanity now uses were dug with a shovel. But back then, there were simply no excavators. So why dig a pit with a shovel now that there are excavators?
The point is that what you mean by "shovel" is not at all what I mean by "procedural" programming. I'm not talking about it at all, you might say. I'm saying that the methods of solving problems that some people use here are very weak in themselves, so what difference does it make - excavator or shovel, if they're both not used effectively?
It's a matter of professionalism, and its absence cannot be replaced with a tool...
And if you have professionalism, you can build mountains using procedural methods. Believe me.
The point is that what you mean by "shovelware" is not at all what I mean by "procedural" programming. I'm not talking about it at all, you might say. I'm saying that the methods of solving problems that some people use here are very weak in themselves, so what difference does it make - excavator or shovel, if they're both not used effectively?
It's a matter of professionalism, and its absence cannot be replaced with a tool...
And if you have professionalism, you can build mountains using procedural methods. Believe me.
I don't disagree, but I'd rather spend my energy on becoming a professional excavator operator than a professional digger.
And I don't know what you mean by "procedural" programming, but I know that OOP is an evolutionary development of procedural programming.
1.Made some include classes based on the article. Just don't understand why to use classes instead of just making a include file with callable functions?
2.I have a question, to improve optimization speed is it better to split the include files into several or put everything in one?
3. I have a feeling that if I call the indicator in a include file, rather than in an EA, the optimization speed is faster...?
The mystery is clear - it's an article :-) there's code for the sake of code and the volume of the article itself... "don't read the newspaper before you eat" :-)
The point is that what you mean by "shovelware" is not at all what I mean by "procedural" programming. I'm not talking about it at all, you might say. I'm saying that the methods of solving problems that some people use here are very weak in themselves, so what difference does it make - excavator or shovel, if they're both not used effectively?
It's a matter of professionalism, and its absence cannot be replaced with a tool...
And if you have professionalism, you can build mountains using procedural methods as well. Trust me.
In general, Peter, I have the feeling that you look at your pit, dug with a shovel, and look at the neighbour's pit, dug with an excavator. You compare and see that your trench is bigger and has flatter edges. And you conclude that it's better to dig with a shovel. Can you imagine if you learned to dig with an excavator... and you can even up the edges with a shovel.
And, in general, Peter, I have the feeling that you look at your pit, dug with a shovel, and you look at your neighbour's pit, dug with an excavator. You compare and see that your trench is bigger and has flatter edges. And you conclude that it's better to dig with a shovel. Can you imagine if you learned to dig with an excavator... ...and you can even out the edges with a shovel.
Nikolai, if you compare tools, I wasn't digging with a shovel at all. It's a different tool, a much cooler one. I haven't figured out what to call it yet, but it's quite possible that you can't keep up with an excavator. The future will tell...
In general, I respect an excavator as a tool, but I had no time to study it. Another idea took hold).
Nikolai, if you compare tools, I wasn't digging with a shovel at all. It's a different tool, a much cooler one. I haven't figured out what to call it yet, but it's quite possible that I can't keep up with an excavator either. The future will tell...
In general, I respect an excavator as a tool, but I had no time to study it. Another idea took hold).
If it's true that you created something cooler than OOP, then will you autograph yours when you become famous?