Errors, bugs, questions - page 1017
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
In short, you can't define a function implementation in .mqh and use it without problems in any .ex5
:)
But when you use one .ex5 to call functions on another .ex5, even though the function with that name exists in both of them, you have to make sure you specify the namespace accurately. That is, the ::In() should, in theory, solve the problem. And if it doesn't - this is a bug that needs to be fixed.
Let's stop with the ServiceDesk answer:
"When compiling 1.mq5, inside function B() it is not clear which function should be called,
imported A() or exported A() - because the compiler does not understand that you meant the same function"
They are right in form - but if you wanted to, the compiler could (and should) be told that it is the same function, as I repeat the name of the module at the time of compilation - is available (specified in #import).
All the more so, if you first put :: in one place and compile, then delete and put :: in another - everything works, but you must agree - it's very inconvenient and after 10-15 such forced permutations I switched to #define
Let's stop with the ServiceDesk answer:
"When compiling 1.mq5, inside the B() function it is not clear which function should be called,
Imported A() or exported A() - as the compiler doesn't understand that you meant the same function"
They are correct in form - but the compiler could (and should) be told that it is the same function if desired, as I repeat the module name is available at the time of compilation (specified in #import).
For such hints there is a context resolution operator "::", but it is not applicable in this case because the module (file) name is also the same.
The advice is adequate - change the structure of the program.
All the more so, if you first put :: and compile in one place and then remove and put :: in another - everything works, but you must agree - it is very inconvenient
and after 10-15 such forced permutations I switched to #define
Parametrized defines are useful only when type sensing is undesirable or when parameters are replaced by "verbose" chunks of text. As a substitute for an inline function, a define is undoubtedly harmful to the health of a program.
--
In your case I would refuse to use .ex5 libraries, and everything would work just fine. The only practical use of them is in hiding implementation (when selling), and I don't see their use in other cases.
Are you writing for sale?
Are you writing for sale?
For myself.
I can't do it without .ex5. I also have functions like F( string& [] ), they somehow don't fit into .dll :)
Perhaps one could push them through a separator, but I haven't tried it yet
MQL5 has just no inline functions (in form) and I use parametric macros instead, which is not quite correct, because there's no type control.
Also, the compiler doesn't optimise expressions, so there's an additional speed penalty. You'd better check.
By the way, about inlining - it works. I had some problems with debugger because of it.
By the way, about the inlining -- it works. There were also problems with the debugger because of it.
So it works at compiler level. And I would like it to work at language level. I gave an example above - everything works through inexplicable "bypassing the compiler", while direct work requires extra steps, sometimes significant, because as you suggested not to include description and implementation of one and the same function in one file is certainly possible, but then 10 complete .mqh is broken down into 100 smaller .mqh
I haven't been chasing speed yet. The main thing is convenience and that the amount of code doesn't grow exponentially.
I've even faced the necessity of using #if #else analogues in MQL5 (it's a bit tricky so far, but it works here and there)
I'm not looking for speed yet. The main thing is convenience and that the volume of code does not grow exponentially.
A100:
It doesn't work without .ex5. I also have functions like F( string& [] ), but they don't fit into .dll somehow :)
....
Geez... :)
I didn't suggest using DLL instead of .ex5 libraries. Just lots and lots of .mqh and one executable .mq5, nothing more.
Just lots and lots of .mqh and one executable .mq5, nothing else.