Алгоритмы, методы решений, сравнение их производительности - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Чем обычный массив интов не подойдет? зачем эти стринги....
Потому что мы заранее не знаем сколько советник совершит сделок. Нужно заранее выделять память под массив, но мы не знаем сколько.
Поэтому нужно было найти решение и быстрое и короткое и не занимающее лишней памяти.
Не совсем.
...
повторюсь представте что вместо стринга у вас использован класс в которм храниться динамический массив чартов - и это по вашему быстро?
Я не знаю внутреннюю реализацию строковых функций, но замер скорости исполнения функции показывает, что время на поиск и возврат меджика из общей строки в тысячи меджиков, занимает менее 100 микросекунд.
По моему, это очень быстро. Врядли можно сделать быстрее.
Потому что мы заранее не знаем сколько советник совершит сделок. Нужно заранее выделять память под массив, но мы не знаем сколько.
Поэтому нужно было найти решение и быстрое и короткое и не занимающее лишней памяти.
На счет быстрое. Измерьте скорость извлечения всех 24000 тысяч меджиков. Неприятно удивитесь.
Готово:
Ваш пример уже не исправить :)
А что будет если вам не хватит размера строки?
В вашем примере может быть 32767 записей(сделок), так вот попробуйте сравнить последний записанный и прочитанный магик.
Вы снова не понимаете о чем речь. Номер сделки назначает торговая система (MetaTrader или биржа). Под номером сделки имеется в виду не порядковый номер сделки, а именно ее тикет возвращаемый функцией HistoryDealGetTicket. Вот с учетом этого и переделайте Ваш пример.
Это не проблема. Завтра сделаю второй вариант, который будет работать с тикетом.
Этот вариант тоже удобен в торговле.
На счет быстрое. Измерьте скорость извлечения всех 24000 тысяч меджиков. Неприятно удивитесь.
Ну в каждый конкретный момент нам же нужен один меджик?
Извлекаем меджик, получаем доступ к какой либо информации связанной с ордером.
Зачем сразу извлекать 24 000 меджиков?
Блин, что я здесь делаю!? На кого я трачу время? Пойду лучше выпью чего-нибудь покрепче.
p.s. Ах, да, у Вас еще одна ошибка. Если MathRand на третьем вызове вернет например число 1000 и запишет _3_1000_, какой меджик будет найден у сделки с порядковым номером 1000?Ваш пример уже не исправить :)
А что будет если вам не хватит размера строки?
В вашем примере может быть 32767 записей(сделок), так вот попробуйте сравнить последний записанный и прочитанный магик.
Спасибо за указание на ограничение длинны строки.
Можно вторую строку начать писать. Потом третью и т.д... :)
Я не знаю внутреннюю реализацию строковых функций, но замер скорости исполнения функции показывает, что время на поиск и возврат меджика из общей строки в тысячи меджиков, занимает менее 100 микросекунд.
По моему, это очень быстро. Врядли можно сделать быстрее.
ну в общем в двух словах стринг одного символа это char с неким кодом от 0 до 255 и весит 1 байт... и выделено под него именно столько памяти чтобы как раз было 256 значений, 257 туда не поместиться оно перемститься обратно на первое.
Да вот в любой страке каждый символ равен число от 0 до 255... получаемться мы берем число инт 10000000 - весит оно 4 байта , перводим его в строку "10000000" потом на каждый символ выделяем памяти как на одельный чарт от 0 до 255... итого 8 байт Тут близко нигде нету экономии памяти