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

Новый комментарий
 
Alexey Viktorov:

Вот и приехали

Выходит что все ваши коды сделаны на костылях? Ничего личного.
Да, примерно так.  Ибо в MQL нет полноценного ООП.  Плюс куча багов, о которых я регулярно рапортую, но безуспешно.  А против багов приходится обороняться костылями, что поделаешь.
 

Вот как мы поступим.

Если static переменная инициализируется константой, то эта инициализация будет происходить на этапе глобальной инициализации, как и раньше
Иначе (инициализация вызовом или переменной), static переменная будет инициализироваться при первом обращении (будет как в C++), само такое обращение будет завёрнуто в условие с неявной глобальной переменной/флагом, например

для MQL кода:

class CFoo { };

void func(bool f)
  {
   if(f)
     {
      static CFoo foo;
      foo.MakeMeHappy();
     }
  }

Будет сгенерирован следующий псевдокод

CFoo static_func_foo={}; // zeromem only
bool static_func_foo_init=false;

void func(bool f)
  {
   if(f)
     {
      if(!static_func_foo_init)
        {
         static_func_foo.CFoo();  // constructor call
         static_func_foo_init=true;
        }

      static_func_foo.MakeMeHappy();
     }
  }
 
Alexey Navoykov:

Вам же всё-равно придётся их в функции как-то разделять.

Совсем даже не обязательно и не всегда. Примеры приводить не буду, чтобы не замусоривать ветку.

 
Ilyas:

Вот как мы поступим.

Отличная новость!  Всё-таки боги услышали наши молитвы )
 
Alexey Navoykov:
Да, примерно так.  Ибо в MQL нет полноценного ООП.  Плюс куча багов, о которых я регулярно рапортую, но безуспешно.  А против багов приходится обороняться костылями, что поделаешь.

Что-то вы меня совсем запутали. Если в ... читайте свои слова

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Особенности языка mql5, тонкости и приёмы работы

Alexey Navoykov, 2019.01.25 11:44

Если параметры разных типов, то логично сделать несколько перегруженных методов с соответствующими типами.  Вам же всё-равно придётся их в функции как-то разделять.  Так лучше разбить на отдельные функции, чем городить портянку, которая к тому же принимает безликий тип, т.е. можно по ошибке передать в неё всё что угодно и получить ошибку компиляции внутри библиотеки, что не есть гуд.  А может даже и не получить, что не гуд вдвойне )

Короче, в полноценном ООП шаблонные функции - это костыль (за редким исключением)

а в MQL нет полноценного ООП... Даже костыли пропали? Совсем ничего не понимаю.
 
В MQL все хорошо с ООП, если множественное наследование добавят (для интерфейсов хотя бы, а то они совсем бесполезны в нынешнем виде), то будет вообще идеально.
 
Ilya Malev:
В MQL все хорошо с ООП, если множественное наследование добавят (для интерфейсов хотя бы, а то они совсем бесполезны в нынешнем виде), то будет вообще идеально.

Так интерфейсы - это основа нормального ООП.  А вы при этом говорите, что в MQL всё хорошо.

 
Alexey Navoykov:

Так интерфейсы - это основа нормального ООП.  А вы при этом говорите, что в MQL всё хорошо.

Основа нормального ООП - это полиморфизм, а не интерфейсы. Интерфейсы - это основа определенной структуры классов. Вообще я бы с удовольствием поговорил на эти темы но боюсь что данная ветка не для этого.

 
Ilya Malev:

Основа нормального ООП - это полиморфизм, а не интерфейсы. Интерфейсы - это основа определенной структуры классов. Вообще я бы с удовольствием поговорил на эти темы но боюсь что данная ветка не для этого.

Ну почему же, ветка вполне подходящая.  Мы ж обсуждаем особенности языка MQL, а отсутствие множественного наследования - это вполне себе особенность )

Ок, основа конечно полиморфизм, но без раздельных интерфейсов - он не удобен в применении. Это зачастую и приводит к тому, что объекты приходится передавать как шаблонные аргументы, а не как интерфейсы.

Я вот тут описывал свой вариант имитации множественных интерфейсов.  Соответственно класс у меня может объявляться так:

class A : public Interface1<Interface2<Interface3<CBase>>>
{
 ...
};
 
Alexey Navoykov:

Ну почему же, ветка вполне подходящая.  Мы ж обсуждаем особенности языка MQL, а отсутствие множественного наследования - это вполне себе особенность )

Ок, основа конечно полиморфизм, но без раздельных интерфейсов - он не удобен в применении. Это зачастую и приводит к тому, что объекты приходится передавать как шаблонные аргументы, а не как интерфейсы.

Я вот тут описывал свой вариант имитации множественных интерфейсов.  Соответственно класс у меня может объявляться так:

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

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