OOP, templates and macros in mql5, subtleties and uses - page 5
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
About multi-passing - rushed, naively thought the mcl would allow it
Ну вот я с этого и начинал разговор тут. Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно). Но как показано выше, с шаблонами такое не прокатит. С макросами тоже. А я всё это широко применяю. Поэтому и сделал свою реализацию. Хотя она конечно не решает всех проблем. Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже. Поэтому их однозначно придётся выносить на глобальный уровень
I also use templates and macros extensively, but consider free functions only as auxiliary (and generally undesirable) architectural elements. When all implementations are packed inside objects and statics are declared only at class level, annoying bugs appear except that sometimes it's hard to understand the logic of their correct sequence of declarations, so that the compiler doesn't swear...
So there are variables here. And with functions, yes, it is multi-passable, so everything was right. The problem arises precisely because of the order of initialization of functions. In short, in C++ there is one strict order that applies to variables, functions and types. And in MQL everything is different.
Multiple passes are bad in any case - you may encounter recursion, deadlocks etc. But on the plus side it can be done. Therefore only wisely, cautiously (i.e. forward declaration), and not as now with multi-pass compiler - as if for any function forward declaration is made, sooner or later this rake will hit your forehead.
Multipassing is bad in any case - you can run into recursion, deadlock, etc. But in pluses it is possible to do forward declaration. Therefore only wisely, carefully, and not as now with multipass compiler - as if for any function forward declaration is made, sooner or later this rake will hit your forehead.
I agree. This topic was discussed a bit earlier. It's what many here like about the language - that you don't bother with the order of functions declaration. Needless to say, I was happy about it myself some time ago). But its tediousness irritated me on the plus side. But with experience comes understanding.
I also use templates and macros extensively, but consider free functions only as auxiliary (and generally undesirable) architectural elements. When all implementations are packed inside objects and statics are declared only at class level, annoying bugs appear except that sometimes it's hard to understand the logic of their correct sequence, so that the compiler won't swear...
I agree, if everything is clearly lined up in OOP, then not only free functions are not needed, but template methods too.
Template methods are needed wherever you don't want to write a bunch of repetitive code, either OOP or non-ODOP. Free functions are another matter - these are different programming styles.
Template methods are needed wherever you don't want to write a bunch of repetitive code, whether it's OOP or non-ODOP
In OOP, interfaces were invented for this purpose.
Interfaces are a bit different. If I want the same code to do the same job with different types depending on the parameter class (without declaring additional classes), interfaces won't help.
Interfaces are a bit different. If I want the same code to do the same job with different types depending on the parameter class (without declaring additional classes), the interface won't help.
If the parameters are of different types, then it makes sense to make several overloaded methods with corresponding types. You'll still have to separate them somehow in the function. So it's better to divide them into separate functions, than to create a mess that also takes an impersonal type, i.e. by mistake you can pass anything into it and get a compilation error inside the library, which is not good. And maybe even not, which is doubly bad).
In short, in full-fledged OOP template functions are a crutch (with few exceptions)
In short, template functions are a crutch in full-fledged OOP.
So here we are.
Forum on trading, automated trading systems and trading strategies testing
Features of mql5 language, tips and tricks
Alexey Navoykov, 2019.01.25 10:11
Well, that's how I started the conversation here. I was planning to replace all statics with globals too (although it's a cruel thing, of course). But as shown above, it won't work with templates and macros too. And I use them all widely. That's why I made my own implementation. Although it doesn't solve all the problems. Dynamic arrays still can't be initialized, neither can the constant types. That's why they will definitely have to be globalized.