Краткая суть бага: Когда есть наследование классов A <= B <= C <= D и реализованы две overloading функции, например одна c параметра А*, а вторая с B*, то передача в такую функцию объекта C* или D* в MQL вызывает ошибку компиляции "ambiguous call to overloaded function".
Вопрос: есть ли более вменяемый обход этого идиотского бага, чем представленный выше?
Краткая суть бага: Когда есть наследование классов A <= B <= C <= D и реализованы две функции, например одна для параметра А*, вторая для B*, то передача в такую функцию объекта C* или D* в MQL вызывает ошибку компиляции "ambiguous call to overloaded function".
Вопрос: есть ли более вменяемый обход этого идиотского бага, чем представленный выше?
Ну не перекладывается STL один в один. Тут надо с большим оглядом на специфику. Проще всего весь возможный функционал абстрактными методами в базовом классе или интерфейсе прописать, а в наследниках - или реализацию, или =delte. В этом случае передаются в методы указатели или ссылки с типом этого самого базового класса. Правда тут неизбежное зло в виде виртуальной таблицы, но это бог с ним, а вот архитектуру желательно выстроить, что бы не было нигде дорогого ветвления через dynamic_cast.
Ну не перекладывается STL один в один. Тут надо с большим оглядом на специфику.
Вы путаете теплое с мягким. Вопрос не в STL. Там сам разберусь... (если у кого-то не перекладывается, это не означает, что это не возможно в принципе сделать)
Проще всего весь возможный функционал абстрактными методами в базовом классе или интерфейсе прописать, а в наследниках - или реализацию, или =delte. В этом случае передаются в методы указатели или ссылки с типом этого самого базового класса. Правда тут неизбежное зло в виде виртуальной таблицы, но это бог с ним, а вот архитектуру желательно выстроить, что бы не было нигде дорогого ветвления через dynamic_cast.
Баг в приоритетах вызова перезагруженных функций, когда для параметра указателя/класса выполняется implicit type conversion. В С++ - все ОК, а в MQL - ошибка компиляции "ambiguous call to overloaded function" Выше предложен один из вариантов обхода, но он большой и не удобный, и использовать его еще для десятка таких же функций желания ну ни как нет. Возможно есть что-то по проще???
Баг МТ5(build 2323), внутри шаблонной функции, переданный указатель в рамках операции явного приведения типа ведет себя как класс, вызывая, соответственно, ошибку компиляции:
#define PRINT(x) ; Print(#x, ":", string(x))
template<typename T>
class ClassWrapper{
public:
T data;
};
class ClassA{};
class ClassB : public ClassA{};
template<typename T, typename TT>
void func(const T &_wrapper, const TT &value){
T wrapper = _wrapper;
PRINT(typename(wrapper.data)); // Ok: ClassA*
PRINT(typename(value)); // Ok: ClassA*
PRINT(typename(TT)); // Ok: ClassA*//wrapper.data = (TT)(value); // Compiler Error: 'value' - object required //wrapper.data = (TT)(wrapper.data); // Compiler Error: 'data' - object required
ClassB b;
PRINT(typename((TT)(b))); // Result: ClassA. During explicit type conversion, TT is "ClassA" instead of "ClassA*"
};
voidOnStart(){
ClassWrapper<ClassA*> a_ptr_wrapper;
ClassA a;
const ClassA* a_ptr = &a;
func(a_ptr_wrapper, a_ptr);
};
Краткая суть бага:
Когда есть наследование классов A <= B <= C <= D
и реализованы две overloading функции, например одна c параметра А*, а вторая с B*,
то передача в такую функцию объекта C* или D* в MQL вызывает ошибку компиляции "ambiguous call to overloaded function".
Вопрос: есть ли более вменяемый обход этого идиотского бага, чем представленный выше?
Пошли очередные простыни "Почему MQL != C++"...
Зачем что-то комментировать, если вы ни как не разобрались в сути вопроса?
Зачем что-то комментировать, если вы ни как не разобрались в сути вопроса?
Затем, что я уже давно открыл тему для подобных выяснений (потому что никто из таких как Вы сами никак этого сделать не могли).
И затем, что разница в языках ни к ошибкам, ни к багам не относится!
MQL понемногу деморализует:
Краткая суть бага:
Когда есть наследование классов A <= B <= C <= D
и реализованы две функции, например одна для параметра А*, вторая для B*,
то передача в такую функцию объекта C* или D* в MQL вызывает ошибку компиляции "ambiguous call to overloaded function".
Вопрос: есть ли более вменяемый обход этого идиотского бага, чем представленный выше?
Ну не перекладывается STL один в один. Тут надо с большим оглядом на специфику. Проще всего весь возможный функционал абстрактными методами в базовом классе или интерфейсе прописать, а в наследниках - или реализацию, или =delte. В этом случае передаются в методы указатели или ссылки с типом этого самого базового класса. Правда тут неизбежное зло в виде виртуальной таблицы, но это бог с ним, а вот архитектуру желательно выстроить, что бы не было нигде дорогого ветвления через dynamic_cast.
Ну не перекладывается STL один в один. Тут надо с большим оглядом на специфику.
Вы путаете теплое с мягким.
Вопрос не в STL. Там сам разберусь... (если у кого-то не перекладывается, это не означает, что это не возможно в принципе сделать)
Проще всего весь возможный функционал абстрактными методами в базовом классе или интерфейсе прописать, а в наследниках - или реализацию, или =delte.
В этом случае передаются в методы указатели или ссылки с типом этого самого базового класса.
Правда тут неизбежное зло в виде виртуальной таблицы, но это бог с ним, а вот архитектуру желательно выстроить, что бы не было нигде дорогого ветвления через dynamic_cast.
Предложенный вами способ был реализован ранее и так же упирается в этот же баг: https://www.mql5.com/ru/forum/1111/page2648#comment_15015191
Баг в приоритетах вызова перезагруженных функций, когда для параметра указателя/класса выполняется implicit type conversion.
В С++ - все ОК, а в MQL - ошибка компиляции "ambiguous call to overloaded function"
Выше предложен один из вариантов обхода, но он большой и не удобный, и использовать его еще для десятка таких же функций желания ну ни как нет.
Возможно есть что-то по проще???
Разработчики, подскажите пожалуйста, планируется ли исправление бага или это архитектурно невозможно?
внутри шаблонной функции, переданный указатель в рамках операции явного приведения типа ведет себя как класс, вызывая, соответственно, ошибку компиляции:
Туплю, не могу решить простую задачу. Нужно при следующих настройках запуска советника понять, что торговля запрещена.
Такая проверка не прокатывает.
OrderCheck - из пушки по воробьям. Прошу подсказать.