OOP, templates and macros in mql5, subtleties and uses - page 14

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. It is better to talk about something in the place where it is, rather than thinking about how the moderator would do it. Otherwise, everything really got blurred into two threads, and now, even if the moderator decides that the discussion should be there or there, it is quite a laborious task to move the discussion normally with preserving the order of the posts and their meaning.
2) Discussing the actions of a moderator isn't every sneeze... It's not every sneeze, but if you want to challenge him publicly, be it for restoring order or calming a frenzy. And if you have an opinion, who forbids you to express it? Maybe your opinion is a very rational suggestion, but you are afraid to say it, so as not to fall under the moderator's unloved menu? So that's bullshit :)
Thanks for the clarification. I thought it best to have the discussion in a separate thread so as not to clutter up the supposedly valuable information in the main thread. If you decide to move the posts, I will discuss where you move them.
It's not like you're a moderator yet, to determine in which thread what is more appropriate. And moderators have already made it clear that discussion of features should not be in the feature branch, but in a separate branch, i.e. here.
In your description, it is not clear at all how to refer uniformly to a class method by reference and by a T-type value. I don't know what you are talking about, but I was talking about this very thing there.
Here's the situation: I realized that not everything can be tailored to the specifics that forum members expect to see in that thread. The discussion here is (and it was there, so I moved it here) about a fairly specific topic, which I decided to separate out into a separate thread. Let there be more general and understandable to the majority of features, and here - classes, tricky ways of work with them, including macros (what a puzzle for many).
Thanks for the clarification. I thought it best to have the discussion in a separate thread so as not to clutter up the supposedly valuable information in the main thread. If you decide to move the posts, I will discuss where you move them.
Let's keep it that way from now on. Just - if possible - copy the example you're discussing from there into your own post, which refers to that example (I'm having trouble figuring out where it started). Or, if you can no longer edit your post, then tell me in private where to paste what from.
Let it stay that way from now on. Just - if possible - copy the discussed example from there into your post, which refers to that example (it's hard for me to figure out what started it here). Or, if you can't already edit your post, then tell me in private where to paste what from.
I already copied the code here from that thread a couple of posts ago, so no additional action is needed, imho.
I already copied the code from that thread a couple of posts ago, so no extra steps are required.
Good.
Update on the topic of interfaces via templates and statics. To be more precise, not interfaces, but rather conveniently parametrizable operations on arbitrary types, implemented through external classes. In this case, the comparison (Comparer) and casting (Caster).
I have partially addressed the previous criticism, the "interface" class (though it's not an interface) is not inherited from the parameter class (such a method hasn't caught on...), and without using dynamic_cast of course. Hopefully this model will look more logical.
How realistic is it to write a macro for this code section?
I have not decided yet on the number of input variables ( input ), I'm tired to correct the allocated section, the macro for one line is not a problem, but how to multiply it to 10-15 linesI do not know
How realistic is it to write a macro for this code section?
have not decided yet on the number of input variables ( input ), tired to correct the selected part, the macro for one line is not a problem, but how to multiply it to 10-15 lines I do not know
I must say straightaway I did not check it on µl, I just ran it through cis preprocessor for testing, µl has peculiarities, so if something goes wrong, please modify it.
got the output (gcc -E):
additional arguments you/donate to ARGS list.
How realistic is it to write a macro for this code section?
I have not decided yet on the number of input variables ( input ), I'm tired to correct the allocated section, the macro for one line is not a problem, but how to multiply it to 10-15 lines I do not know
So far, only so come up with. If the developers had added a variable number of parameters, like in C, it could be shorter.
So far, this is all I've come up with. If developers would screw in variable number of parameters, like in C, it would be possible to make it shorter.
Something I overcomplicated )).
And let them use the first one, it's probably best.
#define TEST(dId)
It's not a problem to write TEST several times.