On one application of the OOP - page 11

[Vasiliy Sokolov]

СанСаныч Фоменко:

Since the announcement of MT5, I've been trying to get an answer to the question:

How much will my EA (or anyone else's) performance increase if I put all this super-duper stuff into it?

I never got an answer...

...

You cannot implement a complex trading algorithm without a developed programming language. Simple solutions at the level of "buy higher than mashka, sell lower" are in the past, in the 80-ies. Consequently, you basically cannot write anything profitable on a limited programming language (luck is not taken into account of course).

[Vasiliy Sokolov]

СанСаныч Фоменко:

...

External libraries are forbidden, hence the R marketplace. If it wasn't for this restriction I would just get rich without any risk on selling very high quality indicators.

...

You know what's stopping a bad dancer?

No one forbids enriching oneself by converting superprofitable statistical methods to MQL code. AlgLib is your help.

But it's all just like your fantasy: "If I had the same one, but with pink buttonholes, I'd have done something that would have made me a top! - Try to write something and sell at least one copy of your product first. Quickly you'll come down to earth and you'll understand that everything is much more complicated than just implementing some stat. method.

[Renat Fatkhullin]

Vasiliy Sokolov:

Unfortunately, interfaces are forbidden in MQL5, which is very unfortunate, although they could have been enabled in a neat move: allowing multiple inheritance of purely abstract classes.

The interfaces in MQL5 work:

class Interface
  {
public:
   virtual void      Do(void)=0;
  };

class MyTest : public Interface
  {
public:
                     MyTest(void) {};
                    ~MyTest(void) {};

   virtual void      Do(void) { Print("Hello!"); }
  };

void OnStart()
  {
   MyTest test;
   test.Do();
  }

[Vasiliy Sokolov]

Renat Fatkhullin:

Interfaces in MQL5 work:

An object must be able to support multiple interfaces, otherwise it becomes meaningless.

[Vasiliy Sokolov]

Unfortunately, only on the level of wishful thinking:

//+------------------------------------------------------------------+
//| Class of all classes                                             |
//+------------------------------------------------------------------+
class CObject
{
};
//+------------------------------------------------------------------+
//| Enumerator interface                                             |
//+------------------------------------------------------------------+
template<typename T>
class IEnumerator
{
public:
   virtual bool MoveNext();
   virtual void Reset();
   virtual T    Current();
};
class CList : public CObject, public IEnumerator
{
   ...
}

That is, as long as IEnumerator is a purely abstract class, multiple inheritance involving it is completely safe.

[Vasiliy Sokolov]

Renat Fatkhullin:

Interfaces in MQL5 work:

Meanwhile, in fact, interfaces still have to be wrapped in long inheritance chains. An example of this is the wonderful library Internal posted by MQ:

IList -> ICollection -> IEnumerable + IEnumerator

[Renat Fatkhullin]

Vasiliy Sokolov:

An object must be able to support multiple interfaces, otherwise it becomes meaningless.

We are already working on this, we need to do it ourselves.

[Vasiliy Sokolov]

Renat Fatkhullin:
We're already working on it, we need it ourselves.

Well done. It will be really cool. Besides, the solution is quite elegant: it's enough to allow multiple inheritance from classes if and only if they are represented as pure abstract classes (contain no data or implementations, all methods are public). I.e. it is not necessary to introduce some specific construct or keyword that is not part of C++ standard.

[Vasiliy Sokolov]

Also on a side note: the Internal library needs to be further developed. It will become a great feature when the interfaces appear. The old CObject will be forgotten like a bad dream.

[TheXpert]

Vasiliy Sokolov:
it is sufficient to allow multiple inheritance from classes if and only if they are represented as purely abstract classes (contain no data or implementations, all methods are public).

... and are not inherited from anyone, otherwise they are still rhombuses.