Any questions from newcomers on MQL4 and MQL5, help and discussion on algorithms and codes - page 1591

 
Maxim Kuznetsov:

with static in mql everything is running and fraught with errors. The code is always built/compiled as a whole, without intermediate obj and declaration of static is just a tribute to tradition.

If one uses static in mql - that's almost 100% from C/C++/C# world ; or one peeked and ridiculously imitates :-)

But there is also __thread__ :-)

If you write static in a module and not in functions, yes. The coder most likely does not know what he/she is doing. :) And what concerns local variables of functions and,local variables of class methods, and also class fields, it's even a very useful thing, I think.

And errors can arise from misunderstanding the conceptof static variables and using them incorrectly as a consequence.
 
MakarFX:

after

add

didn't help) wherever I put it)

 
Mihail Matkovskij:

If you write static in a module and not in a function, yes. The coder probably doesn't know what he's doing. :) And what concerns local variables of functions and,local variables of class methods, and also class fields, it's even a very useful thing, in my opinion.

The way to solve simple naming conflicts is to add m_ a_ bullshit to entities, because compiler does not know about scope and swears.

Two independent programmers should not name functions, classes and global variables the same way. And method and function parameters must be unique. So should local variables.

no static here :-)

sorry, i got it wrong.

 
законопослушный гражданин:

it didn't help) wherever I put it)

If you want to understand the code, look through the logic of the EA, what it does and under what conditions.

I described the whole advisor very clearly, even for beginners, if you do not understand, ask.

If you want to get an EA written for you, as a "law-abiding citizen", go here

 
Maxim Kuznetsov:

The way to resolve simple name conflicts is to add the m_ a_ bullshit to entities because the compiler doesn't know how to scope and swear.

Two independent programmers should not name functions, classes and global variables the same way. And method and function parameters must be unique. So should local variables.

no static here :-)

sorry, i got it wrong.

Tasks can be different and use static variables only to resolve namespace conflicts, of course, you shouldn't (but that's inaccurate... :)). But you can, for example, record how many objects of some class were created. Also, static constants, a very handy thing. Static methods, etc. You may do without static, of course. But all this depends on many factors. The task in hand and ways of solving it. Well, of course, it depends onprogrammers' understanding of the programming concept, in the first place.

 
Mihail Matkovskij:

Tasks can be different and using static variables just to solve namespace conflicts is certainly not a good idea (but it's inaccurate... :)). But, for example, you can write down how many objects of some class were created. Also, static constants, a very handy thing. Static methods, etc. You may do it without static, of course. But all this depends on many factors. The task in hand and ways of solving it. Well, of course, depends onprogrammer's understanding of the programming concept, in the first place.

Now take a library and #include it...

You'll get a lot of conflicts out of the blue. The reason is that you and the author refer to one and the same thing as two reasonable people. In a simple EA, input double SL - and a lot of warnings.

How the hell do I name a stop loss, so it is guaranteed that it will not coincide with anyone (sic!, with the names of parameters of methods), if it is called a stop loss and means exactly that ?

Ooh ! the solution is inp_SL...and m_SL and a_SL from visibility... let the developers drag the meta data and definition areas in the names.

no place to be angry...

 
Maxim Kuznetsov:

Now take some library and #include it to yourself...

you'll have a lot of conflicts out of the blue. Just because two reasonable people, you and the author, referred to one and the same thing as one and the same thing. In a simple EA, input double SL - and a lot of warnings.

How the hell do I name a stop loss, so it is guaranteed that it will not coincide with anyone (sic!, with the names of parameters of methods), if it is called a stop loss and means exactly that ?

Ooh ! the solution is inp_SL...and m_SL and a_SL from visibility... let the developers drag the meta data and definition areas in the names.

no place for anger...

I rarely use string libraries as I'm rarely satisfied with them. I prefer to make my own. But I can use a third-party library, only if I need to create something that has alreadybeen thought up many times before me. And then such third-party libraries often have to tweak (e.g. an error suddenly pops up, or I'm missing some needed functions or methods). And if there are too many such conflicts as you described, it is better to look for another library. Or change the names using automatic substitution, in the most extreme case. But I would not do it.

 
MakarFX:

If you want to understand the code, go through all the logic of the EA, what it does and under what conditions.

I have made the entire EA very clear to you, even for beginners, if you do not understand it, ask.

If you want to get an EA written for you, you can go here, like a "law-abiding citizen".

No, I don't. I want to figure it out on my own.

The MQLQL handbook is written in a different language than I do, so I don't understand some things, but the Expert Advisor is explained, thanks.

 
Maxim Kuznetsov:

Now take some library and #include it to yourself...

you'll have a lot of conflicts out of the blue. Just because two reasonable people, you and the author, referred to one and the same thing as one and the same thing. In a simple EA, input double SL - and a lot of warnings.

How the hell do I name a stop loss, so it is guaranteed that it will not coincide with anyone (sic!, with the names of parameters of methods), if it is called a stop loss and means exactly that ?

Ooh ! the solution is inp_SL...and m_SL and a_SL from visibility... let the developers drag the meta data and definition areas in the names.

no place for anger...

Apparently it's a bit of a nuisance...)) I never see the point in inserting someone else's large binary codes into the body of the program. They either require real instructions or must first be decomposed and understood)))

The generator of unique prefixes in the project is our everything))))

 

I don't understand why everyone is talking about some kind of name conflicts...? It must be about procedural programming... As far as I know, if there are several such conflicts, they can be easily solved with prefixes. That's all there is to it... Why do you have to write so much about it...? :)

Plus, a long time ago, the developers added such a thing as namespace. I don't know about the 4th version, but the 5th one has it for a long time. So, I don't see such a big problem.