Не кидайте камнями - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А ты сравни скорость доступа к элементу Clist со скоростью доступа к элементу массива )) Может, я помешан на скорости, это есть такое, но медленнее на порядок или более.
А вот тут всегда дилемма. Либо скорость доступа, либо скорость добавления/удаления. Каждый раз выбираешь.
Учитывая то, что в mql постоянно дергаешь различные Symbol/Position/Order...Info, не говоря уже об ожидании ответов торговых серверов, со скоростью доступа/добавления к элементам массива/списка вообще можно не заморачиваться. ИМХО.
А ты сравни скорость доступа к элементу Clist со скоростью доступа к элементу массива )) Может, я помешан на скорости, это есть такое, но медленнее на порядок или более.
смысла нет сравнивать, однозначно в списках будет больше операций, но тут вопрос в удобстве использования и в задачах - список безболезненно можно кастрировать в любом месте, а массив обьектов нет
ну и по теме топика - зачем производительность при создании / удалении обьектов? - их что каждый тик по 2 десятка нужно создавать и по десятку удалять?
имхо, удобство использования, безопасность добавления и удаления - тут интереснее списки
А вот тут всегда дилемма. Либо скорость доступа, либо скорость добавления/удаления. Каждый раз выбираешь.
Учитывая то, что в mql постоянно дергаешь различные Symbol/Position/Order...Info, не говоря уже об ожидании ответов торговых серверов, со скоростью доступа/добавления к элементам массива/списка вообще можно не заморачиваться. ИМХО.
Есть хеш-таблицы, там как раз компромисс между скоростью и легкостью. Точнее легкость отличная, а скорость конечно пониже, чем в нативном массиве, но гораздо выше, чем в листе. Я тестировал на скорость несколько хеш-таблиц, самой быстрой оказалась реализация от MQ, но там нет доступа по номеру элемента, только по хешу. То есть надо для имитации массива разработать свои правила формирования уникального ключа.
Например, имеем набор ключей "0", "1", "2", "3". Между "1" и "2" надо вставить элемент. Чтобы не пробегать по всей таблице и не менять ключи, надо придумать какое-то правило. Чисто навскидку, если мы знаем, что вставка будет только одна,
можно сформировать ключ "1-2". В общем, тут нужно думать.
Например, у меня есть класс CPositionManager, там все просто, ключом является номер позиции. Надо бы конечно залезть в хеш-таблицу от MQ и добавить перебор по индексу и в стиле foreach. Кстати, сразу чувствуется, что разрабы в MQ сами не торгуют. Они не понимают, что нужно трейдеру от такого класса. И да, я знаю, что с новой версией МТ5 стандартная библиотека переписывается, этот код надо будет класть куда-то отдельно, в свои закрома )
смысла нет сравнивать, однозначно в списках будет больше операций, но тут вопрос в удобстве использования и в задачах - список безболезненно можно кастрировать в любом месте, а массив обьектов нет
ну и по теме топика - зачем производительность при создании / удалении обьектов? - их что каждый тик по 2 десятка нужно создавать и по десятку удалять?
имхо, удобство использования, безопасность добавления и удаления - тут интереснее списки
А разные бывают задачи-то. Если мы там храним ордера и позиции, как у меня сейчас, то скорость не важна. Но я могу легко предположить, что как-нибудь по пьяне придумаю алгоритм, который потребует именно скорости.
А разные бывают задачи-то. Если мы там храним ордера и позиции, как у меня сейчас, то скорость не важна. Но я могу легко предположить, что как-нибудь по пьяне придумаю алгоритм, который потребует именно скорости.
конечно, поэтому религия и предпочтения в программировании не работают ))) - только здравый смысл, нужна скорость: используем массивы, нужна компактность - используем структуры, нужно удобство - используем списки....