starting to move to OOP and MQL5 seems to be very frustrating!!

New comment
 
There was once a poll here about who is planning when or why or .. (can't remember exactly) to switch to OOP-mq5 or something like that.

The last days I started to think about coding in OOP and MQL5 and I was searching for some examples - may be an indicator to start with?
I found this article about it with a coded example of ATR (and ZigZag) - and I got very, very frustrated!!
The simple ATR-indicator was realised by three files giving totally :


 75 lines <= indicator_atrsample2.mq5
403 lines <= custprevcalculated.mqh
208 lines <= atrsample.mqh
----
686 lines of code totally!!

Even the final indicator (indicator_atrsample2.mq5 and atrsample.mqh) have nearly 300 lines.

I am playing around with my version of the ATR in MQL4 and this has only 64 lines(!) - and I am very much convinced: small is beautiful and smaller even more beatifull.
(Of course without becoming obfuscated!!)

Everybody tells us OOP makes coding easier, better, and faster. But if such a simple thing needs more than 10 times the code it is definitely not easier, better, and faster!

Underneath the code of my ATR! It is sightly different to the original ATR as I use the ema-method for smoothing instead of the sma-method!

Is there an example of an MQL5-indicator in OOP (one abstarct indicator class and ..) that in total has not more than 200 lines?
I'd appreciate to know abou it.

Carl


//+------------------------------------------------------------------+
//|                                                      tinyATR.mq4 |
//|                        Copyright 2014, MetaQuotes Software Corp. |
//|                                              http://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2014, MetaQuotes Software Corp."
#property link      "http://www.mql5.com"
#property version   "1.00"
#property strict
#property indicator_separate_window
#property indicator_buffers 1
#property indicator_plots   1

//--- plot AtrFastOrg
#property indicator_label1  "Atr"
#property indicator_type1   DRAW_LINE
#property indicator_color1  clrRed
#property indicator_style1  STYLE_SOLID
#property indicator_width1  1

#define ema(nw,pr,c) (c >= 0.99 ? nw : (((nw)-(pr))*(c) + pr))                     // ema-method
#define getBars3(r_tot,pv_calc) (pv_calc != 0 ? r_tot - (pv_calc) + 1 : r_tot - 1) // calc. the numbers of bars to calc.

extern int Periods = 6;

//--- indicator buffers
double         AtrBuff[],CoeffAtr;
//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int OnInit()
  {
//--- indicator buffers mapping   
   IndicatorDigits(Digits);
   SetIndexBuffer(0,AtrBuff);
   SetIndexLabel(0,"Atr");
   SetIndexEmptyValue(0,0.0);
   CoeffAtr       = 2.0/(double)(Periods+1==0 ? 6 : Periods+1); // coefficient for ema-method
   IndicatorShortName("Atr(cF: "+(string)Periods+":"+DoubleToString(CoeffAtr,2)+")");
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+

int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
  {
//---
   int b = getBars3(rates_total,prev_calculated);
   while (b-->0) {
      double atrF  = (fmax(High[b],Close[b+1]) - fmin(Low[b],Close[b+1])); // calc ATR
      AtrBuff[b]   = ema(atrF,AtrBuff[b+1], CoeffAtr);                     // smooth by ema method
   }
   return(rates_total);
  }
 
Carl Schreiber:


I am playing around with my version of the ATR in MQL4 and this has only 64 lines(!) - and I am very much convinced: small is beautiful and smaller even more beatifull.

(Of course without becoming obfuscated!!)


Carl



I bet i can do it in less then 64

But not in MQL5 of course and i pointed this out before but nobody believed me.

I just moved back and decided to stick to MQL4.

 

There is absolutely no reason to code a standard indicator like ATR using OOP. What do do ?

There is absolutely no reason to use OOP to code 1 simple indicator, you only have good reasons to use OOP if you want to code a lot of indicators or very complex indicators.

OOP is for complex project and/or code reusability.

 
Alain Verleyen:

There is absolutely no reason to code a standard indicator like ATR using OOP. What do do ?

There is absolutely no reason to use OOP to code 1 simple indicator, you only have good reasons to use OOP if you want to code a lot of indicators or very complex indicators.

OOP is for complex project and/or code reusability.

Sure - it is!! The ATR should be my first indicator of many others based (inherited) from a common base.

But if this simple indicator already is so complicated to realize (additional 300 lines on its base), what about the others more complicated indicators??

Reuseability of 686 lines compared to 64 - what is easier to reuse? Reading and trying to understand 686 lines plus adding your own new idea or writing the idea stand alone with estimated only ~100 lines?

 
You should read some books about OOP concept. There are a lot of things which could be pointed out to answer your naive question, but they'll require a lot of typing. ;-) This is why I suggest just to read what is already typed on the subject.
 
Marco vd Heijden:


I just moved back and decided to stick to MQL4.

I've just decided to stick to MQL4 too (it is my broker choice), but it seems that the future is MT5.

I don't know the differences between them so much, but I think now that, maybe, the best place to start is MQL5 for a newcomer like me who will learn from the ground.

 
Stanislav Korotky:
... but they'll require a lot of typing. ;-) ..

I already started to read about OOP, but I prefer - not only this case - real world examples and facts, instead of abstract comments about theoretical(?) benefits of OOP over the traditional way.

One of the (typical?) OOP examples is summing up the area of different figures, so merging heterogeneous objects - but structs and arrays of struct provides similar things.

Any way, please - this to all the fans of OOP - provide a slim solution of the simple ATR on the base of \Include\Arrays\ ?? You can choose the sma-method to smooth the raw ATR to demonstrate a kind of slim how to use the arrays.?


Beside that I am still going on to try OOP and have a few questions.

1) Is it correct that in MQL4 I am not able to return a pointer of a data-array of a class by a public method? (Docs always say what can be done - 'not what not' or this is hard to find).

2) Would I be able to return a 'read-only' pointer to a protected data-array of a class - I haven't MT5 installed it yet? This is instead of returning element by element and/or to avoid to copy the whole array.

May be some will say this is against the ideas of OOP - may be! But at the moment I just want to know what can I do and what's impossible, even if I don't know yet whether I really would need this 'feature'.

In this example I'd like to know whether I can return a 'read-only' pointer to MqlArr[]?

#include <Object.mqh>
class MyCQtsArray : public CObject {

protected: // 
   MqlRates  MqlArr[];    // data array
   MqlRates  voidElement; // void element in case of error
   int       sz;          // array size         
public:
   MqlRates  getRate(int i);
}

MqlRates MyCQtsArray::getRate(int i) {
   if (i<sz) {
      return(¢q[i]); // returns a copy of this element - right?
   } 
   //error:
   return( voidElement );
}

Thanks in advance!!

calli

 
Carl Schreiber:

I already started to read about OOP, but I prefer - not only this case - real world examples and facts, instead of abstract comments about theoretical(?) benefits of OOP over the traditional way.

One of the (typical?) OOP examples is summing up the area of different figures, so merging heterogeneous objects - but structs and arrays of struct provides similar things.

Any way, please - this to all the fans of OOP - provide a slim solution of the simple ATR on the base of \Include\Arrays\ ?? You can choose the sma-method to smooth the raw ATR to demonstrate a kind of slim how to use the arrays.?


Beside that I am still going on to try OOP and have a few questions.

1) Is it correct that in MQL4 I am not able to return a pointer of a data-array of a class by a public method? (Docs always say what can be done - 'not what not' or this is hard to find).

2) Would I be able to return a 'read-only' pointer to a protected data-array of a class - I haven't MT5 installed it yet? This is instead of returning element by element and/or to avoid to copy the whole array.

May be some will say this is against the ideas of OOP - may be! But at the moment I just want to know what can I do and what's impossible, even if I don't know yet whether I really would need this 'feature'.

In this example I'd like to know whether I can return a 'read-only' pointer to MqlArr[]?


Thanks in advance!!

calli

Not sure what a (read-only) pointer to array means in MQL, but you cannot return an array from a function in general.

Anyway, you may refer the array in the object, if you declare the array public instead of protected. Not quite the best practise, but for e.g. assigning the indicator buffers the only way I know of.

 

It's correct.

For MQL4: indicator on custom buffer is not supported yet.

 
Gok.han:

I've just decided to stick to MQL4 too (it is my broker choice), but it seems that the future is MT5.

I don't know the differences between them so much, but I think now that, maybe, the best place to start is MQL5 for a newcomer like me who will learn from the ground.

This topic is not about mql4 or mql5, it's about OOP, which is available and work the same on both languages.
 
Carl Schreiber:

Sure - it is!! The ATR should be my first indicator of many others based (inherited) from a common base.

But if this simple indicator already is so complicated to realize (additional 300 lines on its base), what about the others more complicated indicators??

Reuseability of 686 lines compared to 64 - what is easier to reuse? Reading and trying to understand 686 lines plus adding your own new idea or writing the idea stand alone with estimated only ~100 lines?

The number of lines is irrelevant. Either you have a benefit to use OOP or not.

I am afraid you will have to find your own way to OOP and mql. Each one has it's own idea about how to code and use it.

In this example I'd like to know whether I can return a 'read-only' pointer to MqlArr[]?

You can't, MqlRates is a structure, you can't use pointer on structure.

12
New comment
Reason: