Будут ли конструкторы с параметрами - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
да, так оно и есть, но без исключений можно обойтись, пусть будут постоянные проверки критичных участков кода, лично я заинтересован в скорейшем выходе стабильно работающего билда МТ5, т.к. постоянные "кривозалатанные" обновления вызывают только не желание переходить на новую платформу, а добавление исключений потребует дополнительное время от разработчиков. К слову, я бы очень хотел бы иметь полнофункциональную работу с графикой - некий canvas, возможность создавать ChildWindow и checkbox, но у разработчиков свои планы по созданию МТ5. По большому счету, никто не запрещает сделать свой мост между терминалом и сторонней программой через dll, разработчики утверждают, что вызов dll теперь очень быстрый
С красным я полностью согласен!
И если бы разработчики сказали бы: Что вы хотите, исключения или стабильный билд, я бы выбрал, конечно, билд.
Но пока, ни исключений, ни билда :)
Ну, таким образом, мы приходим к пониманию того, что создать нормальную и современную среду для программера для разработки ПО разработчики MQL пока не в состоянии.
Это видно по тому количеству ошибок, которое изначально было в МТ5, и по отсутствию нормальной документации в момент запуска проекта, и по случаям, когда одно лечим, другое рушим. Т.е. полноценное тестирование не проводится.
1. Нормальную и современную среду для разработки ПО?
На основании этих слов я так понимаю мы тут все тестируем нового конкурента для VB, C++, C#, Delphi, Java и прочих монстров из этой области?
Следовательно как я понимаю парням из MQ лавры Майкрософт, Борланда, Интел и прочих спать спокойно мешают?
А я то думал мы тут все дружно тестируем новую торговую платформу, которая имеет свой специализированный язык (который только от части связан с С++).
Кстати, эти парни вроде как доказали что умеют создавать подобные решения (хотя некоторые до сих пор и сомневаются в этом). Может я не прав?
2. А в ОС Windows ошибок то наверное нет? Может в конфигурациях 1С:Предприятие их мало? Может есть где-то программное обеспечение подобных размеров без багов?
Может MT5 делают не люди (или сотрудникам MQ уже на законодательном уровне ошибаться запрещено)?
3. А что есть "полноценное тестирование"?
falkov:
Убогий редактор (хотя уважаемый Ренат не считает его таким) И огромное время, конца которому пока нет, вывода МТ5 в релиз.
Жизненно важные :) причины добавления исключений: весь программистский мир использует их, потому что это удобно и надежно.
Может назовете пару торговых комплексов для торговли на биржах от Майкрософт, у Интела может есть подобные решения? Ну у парней из 1С они точно должны быть :)
Еще раз повторю - Не стоит сравнивать MQL и C++ с точки зрения абсолютной совместимости. Новые возможности со временем обязательно будут, возможно когда-то добавят и исключения.
Но сейчас об этом рано говорить и думать.
Кстати, многопоточность - это тоже хорошо. И почему Вы считаете, что это снизит безопасность ПО? Туча программ пишется с использованием ее.
Пишутся конечно тучи. Сколько из них являются правильно и грамотно реализованными клиент-серверными решениями?
А синхронизировать данные в терминале наверное ПУШКИН будет (или теперь каждому трейдеру придется кроме основ ООП изучать еще и основы работы с потоками)?
95% народу или совсем не будет это юзать, или будет юзать с ошибками.
Так вот и вопрос - зачем ломать и перестраивать готовое здание если там осталось сделать только отделочные работы?
PS
При этом разработчики давно уже высказали свое точку зрения по поводу подобных инноваций, и пытаться переубедить их такими аргументами не стоит.
falkov:
Причем, сначала Вы говорите, "Неужели с помощью MQL5 будем ракеты в космос запускать и управлять самолетами?" - т.е. надежность не сильно важна.
А потом "ПОЧЕМУ РАЗРАБОТЧИКИ ДОЛЖНЫ ЖЕРТВОВАТЬ БЕЗОПАСНОСТЬЮ В ДЛЯ РАСШИРЕНИЯ ФУНКЦИОНАЛА?" - т.е. безопасность все-таки важна.
В первой части речь шла не о надежности, а об функционале. Года полтора уже знаком с MQL5 и как-то умудрялся до этого обходиться без исключений.
Хотя помнится по началу тоже просил их добавить, но после ответа разработчиков вспомнилась фраза одного из авторов книг по FoxPro, которая звучала примерно так - Есть много способов содрать с кошки шкуру.
falkov:
И если бы разработчики сказали бы: Что вы хотите, исключения или стабильный билд, я бы выбрал, конечно, билд.
Если бы разработчики дали выбор между исключениями и параметрами в OnTrade() я бы без раздумий выбрал второе. Наверное и куча народа тоже.
А насколько работоспособный билд и как скоробудут реальные счета не нам решать, да и будет это не раньше появления режима визуального тестирован и окончания очередного чемпионата.
ИМХО
IgorM:
Нужен (управляемый программистом) механизм возвращения неудачи конструктора
Это вовсе не обязательно реализовывать через исключения. Помнится в TurboPascal'e была псевдопроцедура fail для этих целей. Она прекращала выполнение конструктора и принуждала new вернуть пустой указатель. Это было ещё до введения в Делфи механизма исключений. Исправно всё работало.
А смысл? Имхо, если объект не создался, значит все очень плохо -- это ведь не самостоятельный код. Тупо завершается выполнение и все, имхо.
Завершается выполнение чего? Всей программы? Не. Это не наш путь.
Нужно только чтоб завершался конструктор, и при этом new возвращал пустой указатель. Всю программу грохать крайне нежелательно.
Не. Это не наш путь.
Ну можно объекты юзать исключительно через указатели. Кстати, это хороший вариант, имхо -- сделать возможность вызова конструктора с параметрами только через оператор new.
Ну можно объекты юзать исключительно через указатели. Кстати, это хороший вариант, имхо -- сделать возможность вызова конструктора с параметрами только через оператор new.
Хорошо бы, но как тогда компилятору воспринимать если конструктор описан с параметром а объект создаётся статично?
Придётся описывать перегрузку конструктора.
Хорошо бы, но как тогда компилятору воспринимать если конструктор описан с параметром а объект создаётся статично?
Придётся описывать перегрузку конструктора.
Третий день размышляю. Пришёл пока к выводам:
1) Конструкторы распределяющие память для дочерних объектов - зло.
2) Конструкторы вызывающие виртуальные функции - зло.
Кароче, в конструкторах - минимум кода. Динамические поля инициализировать вдогонку, в Inite(....).
--
Наличие параметров в общем-то ни при чём. Без параметров ничуть не лучше. :)
Третий день размышляю. Пришёл пока к выводам:
1) Конструкторы распределяющие память для дочерних объектов - зло.
2) Конструкторы вызывающие виртуальные функции - зло.