Questions on OOP in MQL5 - page 65

New comment
 
Sergey Dzyublik:

Something you forgot about structures and classes (without new) - they both stand out on the stack.

Not to be confused with C++, it's closer to Sharp

 
Maxim Kuznetsov:

Not to be confused with C++, it's closer to Sharp

This is your fantasy, not reality.
You shouldn't prove what you haven't tested yourself...
Creating local variables as objects of structures and classes (without new) happens on the stack.
I described earlier how arrayswork in MT5.

 
Dmitry Fedoseev:

What a bummer!

1 - Through object creation. 2 - simply through a normal function call. The first number is the time in milliseconds, don't pay attention to the second one.

It's almost 10 times faster (and sometimes more than 10 times faster). What a sad thing... stack... pile... ***cha

Well, why not pay attention? Let me guess: INT_MAX once performed an action via creation of a temporary object, and then the same action via a function call?

Well, it's an expected result, considering that we're still dancing around creation of the class in the runtime (we still should get this handle which looks like an index in some container).

PS. Where's the source code for replay?

PPS. Are you sure that the function was called? Anyway, the optimizer is in this code too, not the fact that there will be a function call in run-time:

for (int i=0;i<500;++i){
   int x=Get(i);}

int Get(int x) {return -x;}

The fact that UB is in mql proves this code:

void OnStart(){
   Print(Test()?"Ok":"No");
}

bool Test (void)
{
  const int MAX = 1000;
  int a=1,b=1,c=1;
  while (1) {
    if (((a*a*a) == ((b*b*b)+(c*c*c)))) return true;
    a++;
    int x=Get(a);
    if (a>MAX) {
      a=1;
      b++;
    }
    if (b>MAX) {
      b=1;
      c++;
    }      
    if (c>MAX) {
      c=1;
    }
  }
  return false;
}
 
Vladimir Simakov:

The fact that mql has UB proves this code:

You have deftly wrapped the compiler around your finger:
- false branch is thrown because there is no break from while(1) loop.
- true is returned because operations are performed on local variables without any interaction with the "outside world" and execution of this code is also thrown out.

 
Sergey Dzyublik:

You have cleverly wrapped the compiler around your finger:
- the false branch is thrown because there is no break from while(1) loop.
- true is returned because operations are performed on local variables without any interaction with the "outside world" and execution of this code is also thrown out.

It's not me - it's one of the examples on the Internet. It's the same as the pluses.

 
Vladimir Simakov:

Why not pay attention? Let me guess: INT_MAX once performed an action via creation of a temporary object and then the same action via function call?

Well, this is an expected result, taking into account that we're still dancing around creation of the class in the runtime (we should get this handle which looks like an index in some container).

PS. Where's the source code for replay?

PPS. Are you sure that the function was called? Anyway, the optimizer is in this code too, not the fact that there will be a function call in run-time:

The fact that UB is in mql proves this code:

You're wrong. You don't have to guess here, just remember yesterday, in case of memory problems, you may look through the quotes to see what the discussion is about. Why did the result suddenly become expected, if before you claimed the opposite?

Yes, I'm sure the function was called. And you all like to dream that I'm an idiot? Why the question is only about the function, and maybe the object wasn't created either? Or are you so sure you know how all compilers work?

 
Sergey Dzyublik:

Can you explain what it's about, because I'm a bit dumb, I've read it three times - but I still don't get it...

Look at the quotations and see what we're talking about. What I quoted, and in response to what I was getting this response from the quote.

 
and every conversation you've ever had has turned into such nonsense... about the stack, about the array string... Your explanation through "on the stack" doesn't work.
 

As Dimitri was too embarrassed to post his code, I had to do 15 min of testing myself.

Oops. With identical operations the difference is only 30%.

class CTest{
   static uint count;
   static double temp;
   int i;
public:
   CTest(int _x):i(_x){++count; temp+=(double)GetMicrosecondCount(); temp/=count;}
   ulong Get() {return GetMicrosecondCount()+i;}
   static uint Count()  {return count;}
   static double Temp() {return temp;}
};

int i=1;
double temp;

uint CTest::count=0;
double CTest::temp=0.0;

void OnStart(){
   ulong t=GetMicrosecondCount();
   for (;i<1000001;++i){
      temp+=(double)CTest(i).Get();
      temp/=i;}
   ulong _t=GetMicrosecondCount()-t;
   Print(_t," | ",i);
   Print(CTest::Count());
   Print(CTest::Temp());
   t=GetMicrosecondCount();
   for (;i<2000001;++i){
      temp+=(double)Test(i);
      temp/=i;}
   _t=GetMicrosecondCount()-t;
   Print(_t," | ",i);
   Print(temp);
}

ulong Test(int x) {
   static uint count=0;
   static double _temp=0.0;
   ++count;
   _temp+=(double)GetMicrosecondCount();
   _temp/=count;
   return GetMicrosecondCount()+x;}

The runtime difference persists even without all this fuss with static variables and fields. It's the difference in microseconds, not the percentage.

Conclusion: The cost of creating a temporary object on the stack is small enough on my not the fastest computer to be about 30-40 ns/pc (nanosecond), so I should pay attention to it in most cases.

PS. And I thought badly about developers, but no, you just do not have to take people at their word and check them)))

 
Vladimir Simakov:

As Dimitri was too embarrassed to post his code, I had to do 15 min of testing myself.

Oops. With identical operations the difference is only 30%.

The runtime difference persists even without all this fuss with static variables and fields. It's the difference in microseconds, not the percentage.

Conclusion: The cost of creating a temporary object on the stack is small enough on my not the fastest computer to be about 30-40 ns/pc (nanosecond), so I should pay attention to it in most cases.

PS. And I thought badly about the developers, but no, you just do not take people's word and check them)))

And even more do all sorts of different calculations inside, the difference will be even less. Anyway, this test can hardly be called a test of identical functionality.

Besides, the tests themselves are not identical.

1...585960616263646566676869707172...96
New comment