Обсуждение статьи "Язык MQL как средство разметки графического интерфейса MQL-программ (Часть 1)" - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
...
...так как в mql нет делегатов, пришлось понять, что это за блюдо и с чем его едят. Пришлось переписать все стандартные классы. Начал с начала, с CObject. Написал в итоге простую реализацию обработки событий OnTradeTransaction, OnChartEvent, OnTimer с помощью "настоящего" ООП...
.
.
положа руку на сердце - CObject и "Стандартная библиотека" это то ещё наследие 90-х годов :-)
пока не возникнет подобие STL не требующего дополнительных аттрибутов от экземпляров и/или наличия "адама" (гранд-класса/общего предка) будут существенные проблемы - видимая часть которых это объём кода прикладных программ. Они блин очень большие....
положа руку на сердце - CObject и "Стандартная библиотека" это то ещё наследие 90-х годов :-)
пока не возникнет подобие STL не требующего дополнительных аттрибутов от экземпляров и/или наличия "адама" (гранд-класса/общего предка) будут существенные проблемы - видимая часть которых это объём кода прикладных программ. Они блин очень большие....
CObject здесь не главное. ООП != Шаблоны, не надо путать, где используется сила шаблонов, а где сила ООП. Никакой особой потребности ни в ООП, ни тем более в шаблонах при экспретописательстве не возникает, и уж тем более в создании аналога делегата с использованием ООП в то время, когда есть указатели на функции.
Как бы это не было печально, но шутка про "клуб жертв с++" становится реальностью. Странно, что люди наваливают на себя кучу всяких заморочек и считают это крутым кодингом. А по сути, современный программист выродился в подключателя библиотек.CObject здесь не главное. ООП != Шаблоны, не надо путать, где используется сила шаблонов, а где сила ООП. Никакой особой потребности ни в ООП, ни тем более в шаблонах при экспретописательстве не возникает, и уж тем более в создании аналога делегата с использованием ООП в то время, когда есть указатели на функции.
Как бы это не было печально, но шутка про "клуб жертв с++" становится реальностью. Странно, что люди наваливают на себя кучу всяких заморочек и считают это крутым кодингом. А по сути, современный программист выродился в подключателя библиотек."в чём сила, брат?"
подключатели_библиотек должны рулить. Это на самом деле правильно, когда сокращает объём кода и время разработки.
PS/ пока-что все публикуемые статьи (и их наработки, что важнее) являются антитезой программирования - они не влекут повышения эффективности.
"в чём сила, брат?"
подключатели_библиотек должны рулить. Это на самом деле правильно, когда сокращает объём кода и время разработки.
PS/ пока-что все публикуемые статьи (и их наработки, что важнее) являются антитезой программирования - они не влекут повышения эффективности.
Сила в знании, а статьи, как раз дают знания, и ничего другого они должны давать. Повышение эффективности, это дело личное каждого. Повышение эффективности программирования, это конечно хорошо, но не тогда, кода от этого падает удобство для пользователя этой программой.
... А по сути, современный программист выродился в подключателя библиотек.
Скоро он совсем исчезнет, так как собирать "объекты" (именованные группы параметров с предустановленными связями) можно интуитивно и без высшего образования, с поддержкой "интеллектуально-развитой" IDE, которая с "полу-слова" будет "понимать" суть возводимой логической структуры. Среда поумнеет и настанет конец эры специализированных программистов и разнообразия языков. Каждый сможет строить алгоритмы прочтя инструкцию к программе. Естественный процесс, ничего страшного... Странно, что это не началось раньше, а вместо этого расплодились языки повторяющие одну концепцию на разный лад.
XML-я не будет. Вся суть в том, чтобы обойтись MQL. Задача сделать "родную" для MQL систему разметки уровня MVP - без наворотов, но достаточно функциональную и расширяемую для тех, кому потребуется. Во внутреннее устройство можно будет не вдаваться. Просто обычно лучше иметь описание концепции и устройства, чем не иметь.
Я тоже не в восторге от стандартной библиотеки, но выбор в общем-то небогатый, поэтому она является (на данный момент) оптимальным компромиссом между теми немногочисленными совсем мелкими и супер навороченными библиотеками, к которым всё равно есть большие вопросы.
Мнимым светочам в вопросах программирования и создания GUI, объявившим себя таковыми на основе наивных поделок, рекомендуется демонстрировать свои шапкозакидательские настроения в собственных ветках.
...
Мнимым светочам в вопросах программирования и создания GUI, объявившим себя таковыми на основе наивных поделок, рекомендуется демонстрировать свои шапкозакидательские настроения в собственных ветках.
В точку.