ФорумРазделы

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

Новый комментарий
Ilya Malev:

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

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

Так это не компилятор, а уже во время исполнения.  А должен компилятор реагировать.

Вот попробовал в VS 2010 такой вариант:

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

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

B b;

Получаю ошибку компиляции:  Error 1 error LNK2001: unresolved external symbol "public: virtual int __thiscall A::f2(void)" 

А Metaeditor молчком. Нехорошо.

Получается, что вызов функции предка с = 0 превращается в вызов самого себя. Если эту ошибку ловить самостоятельно, то может быть и можно извлечь пользу...
Alexey Navoykov:

Так а должен компилятор реагировать.

Вот попробовал в VS 2010 такой вариант:

Получаю ошибку компиляции:  Error 1 error LNK2001: unresolved external symbol "public: virtual int __thiscall A::f2(void)" 

Metaeditor же молчком. Нехорошо.

Алексей, объясните мне пожалуйста на пальцАх, почему, если mql является подобием С, то он обязательно должен быть абсолютно идентичным и шаг влево, шаг вправо - расстрел?

Только потому, что разработчики неосторожно так выразились? Но ведь любой язык построен на циклах и условиях. Всё остальное в прицепе. Почему-же никто не требует от каких-то других языков похожести в части ООП или ещё в чём-то на С.

Alexey Viktorov:

Алексей, объясните мне пожалуйста на пальцАх, почему, если mql является подобием С, то он обязательно должен быть абсолютно идентичным и шаг влево, шаг вправо - расстрел?

Только потому, что разработчики неосторожно так выразились? Но ведь любой язык построен на циклах и условиях. Всё остальное в прицепе. Почему-же никто не требует от каких-то других языков похожести в части ООП или ещё в чём-то на С.

Речь не идёт о полной идентичности. Речь о том, что тот функционал, который реализован, должен работать корректно и непротиворечиво.  Но вы сначала кричите, мол покажите мне другой язык, где работает по-другому. Мол предъявляйте им тоже претензии.  А после того когда вам приводят в пример C++, в котором работает по-другому (правильно), то начинаете старую волынку, мол MQL - это не C++, он и не должен быть идентичным.  Вы уж определитесь
Alexey Viktorov:

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

Да никак. Ребята просто пытаются свои фантазии натянуть на реальность.

Dmitry Fedoseev:

Да никак. Ребята просто пытаются свои фантазии натянуть на реальность.

Как по мне, так очень даже полезное занятие- натягивать фантазии на реальность. В этом смысл развития!
Очень познавалетьная дискуссия. Спасибо.
Alexey Navoykov:

Это да.  Но я давно пользуюсь альтернативным вариантом:  все интерфейсы изначально оформляю в виде промежуточного шаблонного класса:

Таким образом можно создавать цепочку наследования из любого числа таких интерфейсов.   Да, конечно dynamic_cast с ними не сделаешь, но это не такая уж и частая необходимость.  Главная задача - это передача в функции.

Почитал внимательнее, интересный у Вас ход, кстати. Я до такого не додумывался =) Поэкспериментирую тоже на досуге...

Nikolai Semko:
Как по мне, так очень даже полезное занятие- натягивать фантазии на реальность. В этом смысл развития!
Очень познавалетьная дискуссия. Спасибо.

И главное - плодотворная!  Разработчики таки услышали нас и решили исправить этот баг, об который уже годами все спотыкаются.

А вот деструктивная позиция некоторых форумчан конечно удивляет.  И сами не развиваются - и другим пытаются помешать с поразительной настойчивостью.

>> Да, конечно dynamic_cast с ними не сделаешь, но это не такая уж и частая необходимость.  Главная задача - это передача в функции.

Да почему не делаешь, ноу проблем ) Но тогда появляется Ваш главный кошмар - невыявление ошибок кастинга на этапе компиляции :)

Ilya Malev:

>> Да, конечно dynamic_cast с ними не сделаешь, но это не такая уж и частая необходимость.  Главная задача - это передача в функции.

Да почему не делаешь, ноу проблем ) Но тогда появляется Ваш главный кошмар - невыявление ошибок кастинга на этапе компиляции :)

Да и это всё-равно бессмысленно в общем случае.  Ведь цепочка наследования могла быть какая угодно:  хоть  Interface<CBase>,  хоть Interface<C<B<A<CBase>>>>, вариантов немерено.  Придётся CBase кастить последовательно ко всем возможным вариантам, что нереально.

Я помню собирался реализовать хранение информации об интерфейсах в самом объекте класса.  И в дополнение к существующим интерфейсным прокладкам сделать самостоятельные интерфейсные классы, которые бы работали как обёртка над нашей прокладкой.   Да только потом пришёл к выводу, что это всё лишнее и не нужное.   Практической потребности кастить базовый класс к какому либо интерфейсу я не встречал.  Это просто как-то нелогично.  Единственный вариант - в отладочных целях узнать, поддерживает ли класс данный интерфейс, но для этого кастинг как таковой не нужен.

12345678910111213141516...28
Новый комментарий