ООП vs процедурное программирование - страница 24
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
1. Есть критерий. Главный критерий - скорость работы.
Наглядность кода - это неправильный критерий.
Срочно все переходим на асамблер..... зато быстро.... правда что есть быстро - это правильная организованность всего проекта или скорость отдельных функций
Срочно все переходим на асамблер..... зато быстро.... правда что есть быстро - это правильная организованность всего проекта или скорость отдельных функций
Срочно все переходим на асамблер..... зато быстро.... правда что есть быстро - это правильная организованность всего проекта или скорость отдельных функций
Да нет, продолжайте кодить через ***
Ну, я не согласен.
Наглядность кода - весьма важная вещь, поскольку, наглядный код куда легче поддерживать и модифицировать.
Все верно сказано - я написал нагладную функцию, и потом, фактически, "обфусцировал" ее, сделал ненаглядной и непонятной. Это было вынужденное решение. В данном случае мне было важнее наглядность всего класса. Наглядностью одной, вполне тривиальной функции - я пожертвовал. Конечно, можно было бы вынести тело этой функции в файл .mq5, но я считаю, что интерфейсы не должны разбиваться на два файла, должны полностью описываться в файле заголовка .mqh.
Скорость - тоже надо меть ввиду, но я не думаю, что надо стремиться к "скорости любой ценой". Должна быть разумная достаточность.
Наверно тот самый пункт 3 и для вас тоже
я программирую давно. Еще с выходом МТ3.
С тех пор на mql4 мне удобней писать в процедурном стиле. У меня нет советников на 1001 строку. Кроме того лишь некоторые функции храню в библиотеках.
на MQL5 пользуюсь стандартной библиотекой. Удобная вещь.
В оптимизации кода по читаемости это больше проблема программистов. а вот оптимизацию по быстродействию делать надо чтоб лишний раз не вызывать тяжелые функции. Недавно переделывал с Mql4 на MQL5 одного советника. Воспользовался выложенной здесь библиотекой. поквырял с полдня, разобрался во всех функциях и заработало, но оптимизация шла очень медленно. Обрезал индикатор до 2-х баров - и все стало просто летать.
Вывод прост. Каждый может писать в любом стиле. MQL не совсем тот язык, который требует оптимизации кода, чтоб выиграть пару милисекунд за счет применения процедурного написания. Больше внимания занимают все таки логические задачи. А как они реализованы на скорость практически не влияют.
...
Вывод прост. Каждый может писать в любом стиле. MQL не совсем тот язык, который требует оптимизации кода, чтоб выиграть пару милисекунд за счет применения процедурного написания. Больше внимания занимают все таки логические задачи. А как они реализованы на скорость практически не влияют.
Так мягко незаметно подвели, что именно процедурное программирование обеспечивает высокое быстродействие. Уже три дня дня тут показываю задачу, которую без лишних тормозов позволяет решить только ООП.
ООП позволяет экранировать наборы переменных от остального кода, что позволят, при выполнении расчетов внутри класса отойти от передачи параметров в метод, а это существенны фактор для быстродействия. Если даже так делать в процедурном стиле, придется плодить огромное количество глобальных переменных, в результате читаемость кода снижается до невозможности.
Так мягко незаметно подвели, что именно процедурное программирование обеспечивает высокое быстродействие. Уже три дня дня тут показываю задачу, которую без лишних тормозов позволяет решить только ООП.
ООП позволяет экранировать наборы переменных от остального кода, что позволят, при выполнении расчетов внутри класса отойти от передачи параметров в метод, а это существенны фактор для быстродействия. Если даже так делать в процедурном стиле, придется плодить огромное количество глобальных переменных, в результате читаемость кода снижается до невозможности.
Выигрыш процедурного стиля ничтожно мал потому как код запускается с приходом каждого тика в советниках. И между тиками может быть сотни а то и десятки милисекунд. С индикаторами никогда не заморачивался. Реальной пользы от индикаторов для себя не придумал.
Большие проекты наверно все таки писать на ООП удобней. Сам предпочтиаю использовать структуры, если надо что-то сохранить.
Доступ к данным тогда более наглядный и выпадающее меню очень удобно пользовать. Если структуры заменить массивами, то часто возникает путаница. и количество массивов растет.
В предыдущем сообщении я ставил акцент именно на вызов тяжелых функций. Например каких-то переборов в циклах, которые не нужно делать на каждом тике. Да и на каждом новом баре тоже делать не обязательно.
Вот где реальный выигрыш в производительности можно увеличить.
Ага. Забавная полемика: Экскаватор vs лопата.
Наверное, если нужно деревце посадить, то лучше лопата. А если котлован вырыть - то, пожалуй, экскаватор все же будет лучше.
Ага. Забавная полемика: Экскаватор vs лопата.
Наверное, если нужно деревце посадить, то лучше лопата. А если котлован вырыть - то, пожалуй, экскаватор все же будет лучше.
Ага. Забавная полемика: Экскаватор vs лопата.
Наверное, если нужно деревце посадить, то лучше лопата. А если котлован вырыть - то, пожалуй, экскаватор все же будет лучше.