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
You mentioned that C lang uses files as a namespace. C uses namespaces as namespaces, contrary to something like python that uses the files themselves are literal namespaces and you can access attribute such as file.variable. Nonetheless, the use of non-const global variables is a code smell that can be avoided with better design.
I said "like namespace". I mean the C language respect the scope of file. Sometimes you just want to write a simple code and you want to use a lot of global variables. It's up to the programmer. Global variables are good if you know how to use it and the subject is not about how to use global variables.
The way MQL language mixes everything is a big problem because the more the project gets bigger the more the possibility to encounter name conflicts.
If you don't agree try to compile the following code. It's a const global variable as you like.
Now, am I a bad designer?
The Trade.mqh is from MetaQuotes. Suppose I include 10 different libraries and each library includes 10 different libraries and ... . See it's growing fast 10x10x10x... Now each library has 100 functions and each function declare 10 local variables. The way MQL works is wrong because with this assumption the compiler warns me not to use more than 1000000000 (one billion) names.
MQLn is not C and it is not C++. Adjust to it.
You should be thankful that such WARNING exists.
I bet you never bother to have a look inside Trade.mqh.
When you declare global consts and/or variables, then as you know too, such globals are visible anywhere.
The compiler WARNS you, in that case, so that you can verify if the conflict might cause unintended side-effects due to name collisions.
The compiler is SMARTER that most developers in deciding which const/variable to use.
But since the compiler is not willing to act like a SMART*SS, not knowing what a sloppy developer's intention, it simply WARNS him/her.
Rename your global variable to avoid the conflict, or rewrite Trade.mqh or choose not to use it at all.
As simple as that.
>> Know your tool then your experiences count.
-sef 2020
The solution is to wrap the import in a namespace, however, there appears to be a bug in the MQL linter and while it says it shadows the variable it does not.
You should be thankful that such WARNING exists.
I bet you never bother to have a look inside Trade.mqh.
When you declare global consts and/or variables, then as you know too, such globals are visible anywhere.
The compiler WARNS you, in that case, so that you can verify if the conflict might cause unintended side-effects due to name collisions.
The compiler is SMARTER that most developers in deciding which const/variable to use.
But since the compiler is not willing to act like a SMART*SS, not knowing what a sloppy developer's intention, it simply WARNS him/her.
Rename your global variable to avoid the conflict, or rewrite Trade.mqh or choose not to use it at all.
As simple as that.
>> Know your tool then your experiences count.
-sef 2020
Why do you bet? I won the bet.
A global variable shouldn't be accessed by an included file and that warning is because the compiler does a nasty thing in the first place. How should I explain this so everyone stop telling me ...?
I explained why this kind of name managing is not good for big projects.
I bet you never bother to understand what I'm talking about.
I bet every experienced compiler designer will agree with me.
>> Understand what I'm talking about then tell me "know your tool then your experiences count."
Why do you bet? I won the bet.
A global variable shouldn't be accessed by an included file and that warning is because the compiler does a nasty thing in the first place. How should I explain this so everyone stop telling me ...?
I explained why this kind of name managing is not good for big projects.
I bet you never bother to understand what I'm talking about.
I bet every experienced compiler designer will agree with me.
>> Understand what I'm talking about then tell me "know your tool then your experiences count."
No need to be so salty about it. I'm not saying it's the best design, but as others have pointed out MQL is its own language and the #include simple copy/pastas the code exactly how it is so if you do include other libraries you NEED a mechanism to tell you when you're shadowing variables. To be honest, I don't think this is a major issue for most developers since most devs prefer to not use globals and instead pass constants as parameters or use a class. In the rare event that I ever need a global then I always follow the common naming convention of adding a "g_" prefix. You wouldn't declare a class member without the "m_" prefix so globals should be treated in the same regard.
That being said, you have discovered an annoying bug in the linter that needs to be addressed by MQ.
PICNIC
It is not user error. It is a bug in the linter/compiler. Here is a minimal reproducible example.
It is not user error. It is a bug in the linter/compiler. Here is a minimal reproducible example.
they must be in the same type i think..
they must be in the same type i think..
No.