Ошибка компилятора - неправильная перегрузка методов - страница 3

 
A100:

Результат:   void C1::f<A<B>>(A<B>&)

Ожидалось: void C2::f<   B  >(A<B>&)

И кроме того ошибка при компиляции:
void OnStart()
{ 
        A<B> a;
        C2::f       (a); //нормально
        C2::f<  B  >(a); //нормально
        C2::f<A<B> >(a); //Error: 'a' - parameter conversion not allowed
}
 
A100:

В MQL этот принцип не работает по принципиальным соображениям.

Ремарка: перефразируя https://www.mql5.com/ru/forum/278274/page3#comment_8641454: назовите мне компилятор (кроме MQL) в котором этот принцип не действует

Мне кажется, вы не совсем правильный вывод сделали из его слов.  Он вообще сначала заявил сгоряча, что MQL не имеет никакого отношения к C++, мол это даже нигде в документации не сказано )  Потом поправился, уточнив что речь идёт о неполном соответствии С++.  Но под неполным соответствием надо понимать лишь определённую разницу в синтаксисе, отсутствие каких-то конструкций.  Но базовые правила, связанные с поведением кода, выбором шаблонов и перегрузок и т.д. должны сохраняться, это же очевидно.  

Я приводил цитату из документации, где сказано, что язык ориентирован на максимальную совместимость с С++.  Так вот грош цена такой совместимости, когда коды ведут себя по разному.  Впрочем вы и сами об этом писали.

Поэтому в данном случае я не вижу тут ничего "принципиального". Просто недоработка.

 
Alexey Navoykov:
Поэтому в данном случае я не вижу тут ничего "принципиального". Просто недоработка.
Сказали что менять поведение не будут https://www.mql5.com/ru/forum/1111/page1206#comment_1075424
Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2014.09.17
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 
Yuriy Asaulenko:

А я вот смотрю на такие темы, и думаю: как хорошо, что я на MQL системы не делаю. Из терминала в С++, и никаких вопросов даже не возникает.)

И, заметьте, ни одной претензии создателям MQL.

Да, вы правы. Программирование на MQL - это что-то из разряда садо-мазо )  Сам часто думаю, какого чёрта я себя мучаю...
 
A100:
Сказали что менять поведение не будут https://www.mql5.com/ru/forum/1111/page1206#comment_1075424
Правда это было 4 года назад... может быть уже пора и пересмотреть
 
A100:
Правда это было 4 года назад... может быть уже пора и пересмотреть

Конечно, 4 года - это большой срок.  Когда-то и сложные объекты не копировались по принципиальным соображениям, и много чего ещё...

Но вообще там же речь шла о в кастинге типов, а это другое.  Здесь у нас шаблон, параметры которого всегда 100% соответствуют принимаемому типу.  Поэтому, имхо, двоякости быть не может.  Если шаблон в наследнике точно соответствует типу, то уже не важно что там в родителе.  А вот если бы шаблон дополнительно имел какие-то нешаблонные аргументы, которые могут кастится, тогда другой разговор.

Поэтому тут действительно 2 ошибки.
 
Alexey Navoykov:
Если шаблон в наследнике точно соответствует типу, то уже не важно что там в родителе.  А вот если бы шаблон дополнительно имел какие-то нешаблонные аргументы, которые могут кастится, тогда другой разговор.Поэтому тут действительно 2 ошибки.

По версии MQL важно потому у базового

void С1::f(A<B>& )

приоритет перед шаблоном производного

template<typename T>
void C2::f(A<T>& )
 

A100

Кстати я подумал насчёт той ситуации с кастингом, там действительно довольно неоднозначно получается.  И по-хорошему, нужно стопорить компиляцию в таких случаях. Может подкинуть им такую идею?

 
A100:

По версии MQL важно потому у базового

приоритет перед шаблоном производного

Да какой такой версии?  Мы пока знаем про версию касательно перегрузок с разными типами.  А про шаблоны мы их версию не слышали.  Или было такое?

 
Alexey Navoykov:

Да какой такой версии?  Мы пока знаем про версию касательно перегрузок с разными типами.  А про шаблоны мы их версию не слышали.  Или было такое?

А почему шаблоны должны отличаться? Если в базовом классе есть лучшая функция то выбирается она... а специализация лучше шаблона по определению (тот же C++ при наличии шаблона и специализации выбирает специализацию). Если шаблон в производном будет лучше специализации в базовом то при одновременном сохранении этого правила будет полная неразбериха

Я пока только одну ошибку вижу: при выполнении

Причина обращения: