Ошибки, баги, вопросы - страница 2415
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
С этим ограничением жили много лет.
Вопрос возник впервые за всё время
Это какое-то драконовское ограничение. Какие обоснования по сегодняшним временам? А как удобно задавать кластеры из кучи символов? Плодить десяток разных параметров? Это удобно?
Обоснования в протоколе обмена с агентом тестирования.
Чтобы задавать кучу символов, запишите эту кучу в текстовый файл и передавайте его, используя #property tester_file
Но при одиночном тесте он же тоже передается агенту тестирования и работает без ограничения.
А почему для static input тоже ограничение, её можно вообще не передавать агенту.
Если даже это не баг примите как запрос на усовершенствование.
Баг компилятора. Выдаёт ошибку неоднозначности, хотя тут всё однозначно. Должен вызываться первый метод как наиболее подходящий. В С++ проверено.
Как определяется подходящий?
Обоснования в протоколе обмена с агентом тестирования.
Чтобы задавать кучу символов, запишите эту кучу в текстовый файл и передавайте его, используя #property tester_file
Как это вяжется с продуктами для конечных пользователей? Раньше ограничение может и было оправдано, но сомневаюсь, основываясь на прочих объемах передаваемых данных. Увеличение предела не несет угроз несовместимости.
Как определяется подходящий?
Если говорить про стандарт C++, то:
13.3 Overload resolution. Overload resolution is a mechanism for selecting the best function to call given a list of expressions that are to be the arguments of the call and a set of candidate functions that can be called based on the context of the call. The selection criteria for the best function are the number of arguments, how well the arguments match the parameter-type-list of the candidate function, how well (for non-static member functions) the object matches the implicit object parameter, and certain other properties of the candidate function. [ Note: The function selected by overload resolution is not guaranteed to be appropriate for the context. Other restrictions, such as the accessibility of the function, can make its use in the calling context ill-formed.
Т.е. должно работать так:
Если говорить про стандарт C++, то:
13.3 Overload resolution. Overload resolution is a mechanism for selecting the best function to call given a list of expressions that are to be the arguments of the call and a set of candidate functions that can be called based on the context of the call. The selection criteria for the best function are the number of arguments, how well the arguments match the parameter-type-list of the candidate function, how well (for non-static member functions) the object matches the implicit object parameter, and certain other properties of the candidate function. [ Note: The function selected by overload resolution is not guaranteed to be appropriate for the context. Other restrictions, such as the accessibility of the function, can make its use in the calling context ill-formed.
Т.е. должно работать так:
Для b2 полная однозначность. b1 - нет.
Как определяется подходящий?
Ну очевидно тот, который наиболее соответствует сигнатуре вызова. В данном примере запрашивается метод неконстантного объекта, соответственно при прочих равных условиях должен вызываться именно он.
Если убрать оттуда кастинг, сделав аргумент типа int для обоих методов, то компилируется нормально. Т.е. затык в MQL именно из-за кастинга. Этот кастинг не должен влиять, т.к. он идентичный
Для b2 полная однозначность. b1 - нет.
Тут не нужно однозначности. Должен быть просто порядок применения перегруженных методов. Т.е. задача решения перегрузки не в создании делемм, а в выборе лучшего подходящего метода. Если отбросить модификатор доступа, то берется первый метод из таблицы или же зависит от реализации компилятора, но неоднозначности тут нет.
Вот если бы было 2 метода, с разными входными параметрами например:
Возвращаясь к C++, у того же вектора есть:
Так что это абсолютно нормальная ситуация.
Как это вяжется с продуктами для конечных пользователей? Раньше ограничение может и было оправдано, но сомневаюсь, основываясь на прочих объемах передаваемых данных. Увеличение предела не несет угроз несовместимости.
Начнём с того, что в кеше оптимизации, и в MT5, и в MT4 строковые параметры всегда усекались до 63 символов.
При передаче событий строка тоже не может быть длиннее 63 символов
То есть, то что приходит снаружи - ограничено
Что касается продуктов для конечных пользователей. Продавец должен учитывать ограничения. И если он их не знает, значит он недостаточно тестировал свой продукт перед продажей