Errors, bugs, questions - page 1017

[Vladimir Gomonov]

A100:

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.

[A100]

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

[Vladimir Gomonov]

A100:

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"

Absolutely, that's the way it is.

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

It is better to avoid such tricks. It is not only inconvenient but also "racially incorrect", "unkosher", "ugly", and "on snot". Attempts to cheat the compiler have a right to exist only if there are no other options for implementing what you want. In this case, there are many.

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?

[A100]

MetaDriver:

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

[TheXpert]

A100:
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.

[A100]

TheXpert:

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)

[TheXpert]

A100:

I'm not looking for speed yet. The main thing is convenience and that the volume of code does not grow exponentially.

It's up to you. But given pathological love of metaquotes to limitations, there is far from zero probability that you will catch a rake or two with such macros.

[Vladimir Gomonov]

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.

[A100]

MetaDriver:

Just lots and lots of .mqh and one executable .mq5, nothing else.

I use one code on 3 different terminals, it means at least one .ex5 (shared by all) must be. And if so - then back to the problem described above - there are only 2 modules - but they don't compile normally.

[A100]

ChartGetInteger( chart_ID, CHART_BRING_TO_TOP, 0, true )
ChartGetInteger( chart_ID, CHART_BRING_TO_TOP, true )

It does not work at non-trading times. What prevents you from putting the schedule on top of all the others at non-trading time ?