Features of the mql5 language, subtleties and tricks - page 113

New comment
 
pavlick_:

I don't see why my solution is any worse, I'll put it in here as well:

Because it was originally a "see how I do it" performance and it required exactly the solution that had been thought up beforehand. And yours didn't fit into the production.

But even the director didn't take into account that according to the documentation the order of calculating the parameters is not guaranteed

 
A100:

But even the director did not take into account that according to the Documentation, the order of calculation of parameters is not guaranteed.

To be fair, the MQL documentation does describe this:

Note

You must remember that parameters are passed to the function backwards, i.e., the most recent parameter is calculated and passed first, then the penultimate one, and so on. The parameter that comes first after the opening bracket is calculated and transmitted last.

This is certainly crazy from the C++ point of view, but if it is a documented rule in MQL, it might be ok, if you do not plan to port your code in the future. And if you do, you can secure this place by checking #ifdef __MQL__.

 
A100:

The order in which the parameters are calculated is not guaranteed

I just paid attention to your link. Indeed, it is not guaranteed. What a contradictory MQL ))

 
Alexey Navoykov:

Just now paid attention to your link. Indeed, it's not guaranteed there. That's the controversial MQL ))

On x32 reverse (I think it will save), because there is a direct link to the stack. While on x64 there is no sense in the reverse one and that's why there are no guarantees for the future... moreover it looks unnatural there

I won't even be surprised if the order is different with and without optimization

 

For all the options offered, I would like to say thank you. You have constructively helped to solve a practical problem.


The task was well demonstrated that it would not work if void TimeCurrent() would fail. The void in its current form is able to cripple many things.

 

I want to call the parent method

Here's the code, what am I doing wrong ?

//+------------------------------------------------------------------+
class A
  {
public:
   virtual int Test_A()
     {
      return 100;
     }
  };
//+------------------------------------------------------------------+
class B :public A
  {
public:
   virtual int Test_A()
     {
      return 200;
     }
  };

B b;
//+------------------------------------------------------------------+
void OnStart()
  {
   Comment (A::b.Test_A());
  }
//+------------------------------------------------------------------+


 
Vladimir Pastushak:

I want to call a parent method

the correct syntax is like this:

b.A::Test_A()

but in mql there is neither right nor wrong.

But the question is more for you - if a function needs to be called from a derived one, why put it in a base virtual function?

 

fxsaber:

The task showed well that if the void TimeCurrent() was called, nothing would work. The void in its current form is able to mutilate a lot of things.

At a glance:

#define  MACROSV(NEW_HANDLE_, VOIDFN_) \
do{                                   \
   int prev=GetHandle();              \
   if(SelectHandle(NEW_HANDLE_))      \
      VOIDFN_;                        \
   SelectHandle(prev);                \
}while(false)

Two macros don't seem to hurt much. Something more elegant, by the power of μl, doesn't come to mind.

 
pavlick_:

Off the top of my head:

Why do...while? The curly braces alone are enough.
 
Alexey Navoykov:
Why do...while? The curly braces alone are enough.

To make it work:

if(...)
   MACROSV(...);
else
{
}
1...106107108109110111112113114115116117118119120...266
New comment