Talking about the PLO in the lounge - page 9

New comment
 
fxsaber:

Apparently static and const (this is not OOP) are not needed.

As for OOP, it is very interesting how the following, which has wide practical application (not abstract at all), function would look like in procedural style?

Obviously, any OOP can be rewritten in procedural style. But I'm interested in practice. So I took the above tiny code, where OOP is also used to a minimum.

So how much nicer/more convenient/more readable/more correct is procedural style compared to OOP in this example? Well, not to talk for a few pages, but just to compare short source code procedural vs OOP. I ask OOP opponents to show a masterclass. This is not the dreaded MT5, but good old MT4.

I am not against OOP. Just one of bad quality and cryptic code. (I am not an opponent of OOP. Just one of bad quality and cryptic code)

#define  MC 200
#define  MYOWNSELECT        OrderSelect     
#define  MYOWNTICKET        OrderTicket
#define  MYOWNOTIPE         OrderType
#define  MYOWNOLOT          OrderLots
// Возвращает true только в случае, если с последнего вызова произошли торговые изменения
bool IsChanged_NoOOP_Cryptic_aka_fxsaber(void)
{
  static int ptot=0,tickets[MC],types[MC];
  static double lots[MC];

  int total;
  bool res=ptot!=(total=::OrdersTotal());

  for(int i=0,j=0; i<total; i++)
     if(MYOWNSELECT(i,SELECT_BY_POS))
     {
       if(res=(res || (tickets[j]!=MYOWNTICKET() || types[j]!=MYOWNOTIPE() || lots[j]!=MYOWNOLOT())))
       {
         tickets[j]=MYOWNTICKET();
         types[j]=MYOWNOTIPE();
         lots[j]=MYOWNOLOT();
       }

       j++;
     }
  ptot=total;

  return(res);
}
 
Dennis Kirichenko:

I'm very sorry, in the context of which language are you drawing this conclusion? :-)




Denis, in the context of the forum ))))))))))

 
Alain Verleyen:

I'm not against OOP. Just one of bad quality and cryptic code. (I am not an opponent of OOP. Just one of bad quality and cryptic code)

Thanks for the procedural code! Tweaked it a bit.

#define  MC 200
#define  MYOWNSELECT        OrderSelect     
#define  MYOWNTICKET        OrderTicket
#define  MYOWNOTIPE         OrderType
#define  MYOWNOLOT          OrderLots
// Возвращает true только в случае, если с последнего вызова произошли торговые изменения
bool IsChanged_NoOOP_Cryptic_aka_fxsaber(void)
{
  static int ptot=0,tickets[MC],types[MC];
  static double lots[MC];

  int total;
  bool res=ptot!=(total=::OrdersTotal());

  int j = 0;
  
  for(int i=0; i<total; i++)
     if(MYOWNSELECT(i,SELECT_BY_POS))
     {
       if(res=(res || (tickets[j]!=MYOWNTICKET() || types[j]!=MYOWNOTIPE() || lots[j]!=MYOWNOLOT())))
       {
         tickets[j]=MYOWNTICKET();
         types[j]=MYOWNOTIPE();
         lots[j]=MYOWNOLOT();
       }

       j++;
     }
  ptot=j;

  return(res);
}


Pros and cons of each of the solutions(OOP-solution) you can now see with your own eyes. Everyone makes his own choice and it's silly to impose a different point of view.

 
Dennis Kirichenko:

I'm very sorry, in the context of which language are you drawing this conclusion? :-)

About the pros, of course.

 
fxsaber:

Thanks for the procedural code! Tweaked it a bit

To make it clear that compactness can be tweaked as well.

#define  MC 200
#define  MYOWNSELECT        OrderSelect     

bool IsChanged_NoOOP_Cryptic_aka_fxsaber(void)
{
  static int ptot=0;
  static string History_Unit[MC];

  string Order_Data;
  int total;
  bool res=ptot!=(total=::OrdersTotal());
  int j = 0, i = total;
  
  while(i-- > 0)
     if(MYOWNSELECT(i,SELECT_BY_POS))
     {
       Order_Data = StringFormat("%u|%u|%.2f", OrderTicket(), OrderType(), OrderLots());
       if(res=(res || History_Unit[j]!=Order_Data)) History_Unit[j]=Order_Data;

       j++;
     }
  ptot=j;

  return(res);
}

You could, of course, see how much the performance would change when comparing structures/arrays/rows. But this is a bit of a task taken out of context, so there's no point

PS And I'm not against OOP. In favour of expediency.

 
Alexander Puzanov:

To make it clear that compactness can be tweaked as well.

You could, of course, see how much the performance would change when comparing structures/arrays/rows. But this is a bit of a task taken out of context, so there's no point

PS And I'm not against OOP. In favour of expediency.

Collapse!

 
Alexander Puzanov:

To make it clear that compactness is something else to tinker with

You could, of course, see how much the performance would change when comparing structures/arrays/rows. But this is a bit of a task taken out of context, so there's no point

PS And I'm not against OOP. In favour of expediency.

Using DEFINE was a joke ;-) Your approach would be very slow. (Usage of DEFINE was a joke ;-) Your approach will be very slow.)

 
Alain Verleyen:

The use of DEFINE was a joke ;-) Your approach will be very slow. (Usage of DEFINE was a joke ;-) Your approach will be very slow.)

Sure. This is joke too - this is a code beautification parade, isn't it?

It's a joke too - a twist in favour of compactness and clarity

---

fxsaber:

It's collapsing!

It's a measurement of a particular implementation, a particular case

 
Alexander Puzanov:

Sure. This is joke too - this is a code beautiness parade, isn't it?

Yes really nice.(I am not able to catch joke yet unfortunately ;-)

Yes, really nice. I am not able to catch joke yet unfortunately ;-)

 
fxsaber:

The pros and cons of each solution(the OOP solution) can now be seen for themselves. Everyone makes their own choice and it is silly to impose a different point of view.

No need to impose, but it is obvious that in a procedural form the logic of code is already visible without extra gestures, and each gesture of a hired programmer costs money to the employer. Therefore if an employer is smart, he will not be fooled by OOP but a clever programmer can twist a tale about progressive OOP to get more money from him taking advantage of his low literacy. :)

12345678910111213141516...23
New comment