ООП, шаблоны и макросы в mql5, тонкости и приёмы использования - страница 8

[Vasiliy Sokolov]

Alexey Navoykov:
Имеете ввиду их стандартную библиотеку? )

Нет, имею в виду, что в MQL нельзя объявить абстрактный виртуальный метод без реализации. В MQL, виртуальные методы базового класса всегда должны иметь реализацию, что чревато озвучеными Вами проблемами. 

[Vasiliy Sokolov]

Ilya Malev:

Не так уж много базовых основных интерфейсов в том же С#

На самом деле очень много.

Ilya Malev:

По-моему, не все так уж плохо. Не так уж много базовых основных интерфейсов в том же С#, по-моему (я не спец по С#), чтобы их методы нельзя было свести к одному базовому суперклассу, а потом наследовать кому что нужно.

П.С. Через конструкции типа <<<<>>>> реализовывать что-то множественное имхо это как-то через одно место. Лучше уж функции делать через операторы например а==b вызывает a.compareto( b ), a[comparer]==b вызывает comparer.compare(a,b) и т.п.

Имхо, ужасная мешанина получиться. 

+ Вызов виртуальных методов не бесплатен. 

[Alexey Navoykov]

Vasiliy Sokolov:

Нет, имею в виду, что в MQL нельзя объявить абстрактный виртуальный метод без реализации. В MQL, виртуальные методы базового класса всегда должны иметь реализацию, что чревато озвучеными Вами проблемами. 

Не очень понял, почему нельзя объявить без реализации?   Абстрактные методы классов уже несколько лет как поддерживаются в MQL.

[Ilya Malev]

Vasiliy Sokolov:

1. На самом деле очень много.

2. Имхо, ужасная мешанина получиться. 

+ Вызов виртуальных методов не бесплатен. 

1. Буду знать.

2. Посмотрим что получится, если удастся довести до ума то что я сейчас делаю, то выложу на форуме)

Не бесплатно - это да. Любое универсальное решение через ООП получается дорогим, но если цель - легко и красиво строить обычные эксперты и индикаторы (без наворотов), то имхо оно того стоит.

[Ilya Malev]

Alexey Navoykov:

Не очень понял, почему нельзя объявить без реализации?   Абстрактные методы классов уже несколько лет как поддерживаются в MQL.

Потому что вот такая запись приведет к ошибке компиляции:

class A
 {
public:
  virtual int f1() = 0;
  virtual int f2() = 0;
 };
 
class B: public A
 {
public:
  virtual int f1(){ return 1; } 
 };
 
void OnStart()
 {
   B b;
 }

[Alexey Navoykov]

Ilya Malev:

Потому что вот такая запись приведет к ошибке компиляции:

Да это понятное дело.  А человек думал, что вообще нельзя объявить такой метод в MQL, насколько я понял из его поста.

[Ilyas]

Мало кто знает (ещё меньше тех кто знает и использует), но чисто-виртуальные функции могут иметь тело

class A
 {
public:
  virtual int f1() = 0;
  virtual int f2() = 0 { return(0); }
 };

Они также обязательно должны быть перегружены в классе потомке

[Ilya Malev]

Ilyas:

Мало кто знает (ещё меньше тех кто знает и использует), но чисто-виртуальные функции могут иметь тело

Они также обязательно должны быть перегружены в классе потомке

То есть интерфейсы все таки могут иметь свой код методов? А вызвать его как-то можно? )

Недавно столкнулся просто с этим...

[Alexey Navoykov]

Хм, интересная фича...  Я так понимаю, это умолчательная реализация, которую можно вызывать в наследниках как A::f2().  Т.е.:

class B : public A
{
  virtual int f2() { return A::f2(); }
};

p.s.  Хотя сейчас попробовал...  Даже если у A::f2() нет тела,  то компилятор никак не реагирует на такой вызов.  Т.е. потом в рантайме придётся отлавливать ошибку.  Да ну нафиг такое.

[Ilya Malev]

Alexey Navoykov:
Хм, интересная фича...  Я так понимаю, это умолчательный метод, чтобы просто вызывать в наследниках A::f2().

Протестировал - Вы правы в общем =)

Alexey Navoykov:
p.s.  Хотя сейчас попробовал...  Даже если у A::f2() нет тела,  то компилятор никак не реагирует на такой вызов.  

У меня отреагировал "stack overflow" )

Видимо это тараканчик все таки...

class A
 {
public:
  virtual int f1() = 0 { return 1; }
  virtual int f2() = 0;
 };
 
class B: public A
 {
public:
  virtual int f1(){ return A::f1(); } 
  virtual int f2(){ return A::f2(); } 
 };
 
void OnStart()
 {
   A*a=new B;
   Print(a.f1());
   Print(a.f2());
 }