Респект и уважуха создателям языка, Но... - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну к примеру вот такой прикол (ошибка в знаке):
StringToDouble("2.25") - вернет 2.25, как и положено, а вот StringToDouble("2,25") вернет нам только 2...
А про неудобство работы с TimeToString(), я вообще молчу. Я конечно понимаю, что такой вид отображения дата и времени является стандартом для MT, но почему бы к примеру не добавить дополнительный параметра позволяющий отображать дату в более привычном глазу (возможно и другому ПО) формате ДД.ММ.ГГГГ....
Задайте режим вывода TIME_SECONDS и Вы получите секунды. Об этом явно в документации сказано. Просто по умолчанию режим вывода TIME_DATE | TIME_MINUTES
Да я знаю что можно использовать TIME_SECONDS, но я полагаю, что условие вывода должны быть такими изначально (а вот для желающих можно и без секунд)...
Потому что наш анализ показал, что при форматировании времени в большинстве случаев секунды не используются. Для желающих можно и с секундами.
А что она должна вернуть? Вы подали на вход два целых числа, перечисленных через запятую
А что она должна вернуть? Вы подали на вход два целых числа, перечисленных через запятую
ну вообще-то (если по-хорошему) можно\нужно былобы достать системный разделитель целой и десятичной долей числа и работать с ним. сам то я уже многоооо лет переставляю запятую на точку сразу после переустановки винды, но ведь не все такие "продвинутые" пользователи.
to Interesting а вообщето спор практически беспредметный. не забывайте что основное что делают МК это совсем не MQL5. главная их разработка нам практически не видна - это торговые сервера. Без них MQL вообще лишен смысла. Так что дайте им возможность "вылизать" как следует всю торговую часть а с MQL.... предлагайте предложения, пишите в сервисдеск... захотят - сделают, не захотят - ... ну чтож это их продукт и видят они его именно таким.
P/S/ я вот давеча просил сделать возможность привязки якоря OBJ_EDIT не только на левый верхний угол а на весь "набор" углов. мне ответили дескать этого нельзя потому что у OBJ_EDIT размер фиксированный... ладно, перебьемся, написал 8 строчек кода которые пересчитывают координаты так как мне хочется в то, как им нужно. и ничего - все работает как я хотел. учитесь правильно пользоваться тем что вам доступно ;)
Он настолько прост, что просто ущербен, Скажем так он ни даёт никаких преимуществ для того для чего он создан - а именно создавать МТС. Нет ни одного элемента языка который облегчил эту задачу. Это всё те же for, while, ++, -- и т.д. Это обычный простой язык программирования. Единственное, что вы сделали выдающееся с этим языком это то что он стал управляемым, что позволяет вам утверждать, что вирусы на этом языке написать нельзя (кажется я правильно понимаю цель?). НО это не достоинство языка, это достоинство среды выполнения вашего языка. Пусть он будет производительным, но это опять не достоинство языка а среды выполнения.
Большинство распространенных языков программирования синтаксически практически одинаковы, поэтому придумывать новые элементы языка не надо. Особенно, когда заботишься о совместимости с C/C++, которой достаточно для привлечения большого количества программистов.
Или Вы знакомы с языком поверхностно или просто не хотите замечать огромный функционал языка. Иначе как понимать "не дает никаких преимуществ для создания МТС" на фоне сотен функций, прямо обеспечивающих доступ к рыночной информации, индикаторам и торговым функциям.
Отсутствие нормальных общепринятых парадигм, например исключений просто не позволяют написать программу, предсказуемо реагирующее на ошибки. Точнее так. написать то можно, но для этого надо приложить на порядок большие усилия.
Незнаю баг, это или так задумано, но думаю это всё-таки от отсутствия исключений, но от StringToDouble нельзя накаким образом добиться информации о том, что на вход подали ошибочное число. Получается, что если на вход подали фигню, то на выходе стойкий 0. При этом GetLastError сохраняет молчание. Такое поведение по меньшей мере преступно. В обычных языках это исключительная ситуация с генерированием исключения. Допустим GetLastError всё-же должен вернуть ошибку в этой функции. Как я должен реагировать на это? Видимо следующим образом
А если таких мест десятки или сотни? Где тут забота о программисте?
Это в теории даже выглядит неприглядно, а на практике выливается в еще бОльшие проблемы. Если бросать исключения в каждом месте, то вместо программы получится кошмар из обработчиков (<5%) или тупой перехват "всех исключений в одном месте"(>95% случаев) или постоянное дописывание в режиме "ой, я тут обработчик забыл добавить", приводящее в финале к "надоело, перехвачу все разом".
Вместо эксепшенов мы используем коды возврата (без фанатизма).
Некоторые языки позволяют работать непосредственно с данными. Например Foxpro позволяет встраивать в код SQL запросы. C# c LINQ позволяет делать тоже самое, но с использованием ООП. Почему вам не подумать в этом направлении. Например подумать о конструкциях, которые облегчат работу с ордерами.
Ну про уборку созданных объёктов самим программистом, я вообще молчу. Не сделали сборщик мусора, ну и бог с ним, есть программисты, всего-то добавить пару строк кода - переживут, ну поломают голову, когда надо удалять объёкты, а когда нет. а мы им ещё несколько свойств, методов и поведений добавим.
А в результате малу помалу и код растёт и распухает как на дрожжях.
Динамически выделяемые массивы по сути являются объектами и автоматически освобождаются в деструкторе при выходе из области видимости, что снимает подавляющее большинство вопросов управления памятью. Для упрощения контроля лучше всего использовать классы, которые сами за собой следят и освобождают ресурсы.
Проблема контроля уборки мусора - надуманная. Контролировать надо, но это очень и очень просто (в большинстве случаев автоматически).Неудобство библиотек
Ну тут сказать могу только одно. Наличие кучи функций и глобальных переменных не упрощает, а существенно усложняют программирование. Ну нет у вас нормальной библиотеки - есть куча функций.
Функции являются API терминала, связывающие внутренние процессы и данные с внешней программой. И чем более развито API, тем более функциональнее среда.
Штатные библиотеки расширяются и будут дальше развиваться. Кроме того, растет MQL5 Codebase, который сейчас глубоко интегрируется в сам терминал, что даст возможность скачивать любые скрипты в один клик.
Подводя резюме вышесказанному, можно сказать. Написать МТС на MQL - можно, но существенно сложнее чем на любом другом современном языке и не обязательно C#.
Вывод абсолютно противоположный.
На MQL5 скрипты, индикаторы и эксперты пишутся очень эффективно, легко и с полным контролем, который недоступен ни другим торговым "недоязыкам" (без возможности торговли), ни обычным языкам программирования.
ps: господа, может перейдете к делу? где Ваши произведения в MQL5 Codebase?
Вы не видели штатную библиотеку, посмотрите торговые классы.
По первой ссылке нужно поправить: слева ссылка на торговые классы есть, а в основной части страницы - нет.
По первой ссылке нужно поправить: слева ссылка на торговые классы есть, а в основной части страницы - нет.