Мой подход. Ядро - Движок. - страница 83
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Движок и советник работают в потоке общения. Каждая ячейка таблицы - несколько симоволов. По мимо этого, - масса других элементов передают свои значения, состояния и прочее. Нужно быстро обмениваться строками и не загружать очередь событий OnChartEvent().
возьмите SQL и не парьте мозг :-)
уж не хочешь ли ты сказать, что у тебя даже мыслей нет, как это сделать с помощью ресурсов и union?
После тебя, Николай.
Ты предложил вариант с юнион, а пример не показал. Потом перешел на CharArrayToString и StringToCharArray. Сейчас опять про юнион говоришь.
То есть, гонять стринг в чар а потом обратно, с последующим разбитием строк (строки содержат сборку из номеров параметров и их значений), это самый лучший вариант решения?
После тебя, Николай.
Петр, скажи, а для передачи double, long и int ты тоже стринги используешь?
Ядро параметров - это один массив. И он имеет тип string. По одной причине, - это универсальный тип. Очень удобно. Записал любое значение, а потом привел к нужному типу.
Иначе, нужно было бы делать много ядер параметров. Каждый, для своего типа значения. В итоге, возникла бы путаница с принадлежностью параметров, их индексацией, местом записи и много чем еще.
Давай без троллинга. Менторский тон не уместен. В этой работе я понимаю больше.
Николай, я же сказал, что попробую твой вариант.)) Значит попробую.
возьмите SQL и не парьте мозг :-)
Как-бы в продолжение про "не парьте мозг" :-)
Я сегодня добрый и совсем не злой..
Пётр, по поводу "визуального программирования" (не то чтобы просто GUI), для развития, чтобы не монстрячить массив-на-массиве,
посмотрите например Oracle. Один из несомненных лидеров
Визуальный редактор бесплатно (вместе с виртуальной машиной) он вот есть ; https://apex.oracle.com/en/
Для старта достаточно книжки из разряда "Начала SQL для чайников" и пары дней свободного времени.
Давай без троллинга. Менторский тон не уместен. В этой работе я понимаю больше.
У меня нет цели тебя в этом разубеждать.
Зачем мне делать неблагодарную работу.Никакого такого тона у меня и не было. Просто я уже несколько раз выкладывал для тебя код, который был значительно быстрее твоего, в надежде, что ты его изучишь и будешь применять более быстрые методы, но ты ни разу не воспользовался этим.
Ядро параметров - это один массив. И он имеет тип string. По одной причине, - это универсальный тип. Очень удобно. Записал любое значение, а потом привел к нужному типу.
Иначе, нужно было бы делать много ядер параметров. Каждый, для своего типа значения. В итоге, возникла бы путаница с принадлежностью параметров, их индексацией, местом записи и много чем еще.
Универсальность - часто синоним тормознутости, а со стрингами тем более.
Приведу один пример.
Я как-то занимался парсингом строки, полученной с криптобиржи с помощью WebRequest. И осуществлял парсинг через библиотеку Сергеева JSON, портированную им из "скоростной библиотеки C++". И обратил внимание, что скорость какая-то ну очень неудовлетворительная. Там как раз все осуществлялось через "универсальные" строки.
Я понял что причина низкой скорости - это стринги и мне захотелось уйти использования стринг-функций и я написал функцию парсинга непосредственно из массива uchar. Результат меня весьма удивил. Моя скорость парсинга оказалась.... (барабанная дробь) в 800 раз выше. Если через JSON парсинг всей строки занимал 0.3 секунды, то через мою функцию меньше пол миллисекунды.
Вот здесь есть пример моего парсинга через массив uchar.
Универсальность - часто синоним тормознутости, а со стрингами тем более.
Приведу один пример.
Я как-то занимался парсингом строки, полученной с криптобиржи с помощью WebRequest. И осуществлял парсинг через библиотеку Сергеева JSON, портированную им из "скоростной библиотеки C++". И обратил внимание, что скорость какая-то ну очень неудовлетворительная. Там как раз все осуществлялось через "универсальные" строки.
Мне захотелось уйти от стрингов и я написал функцию парсинга непосредственно из массива uchar. Результат меня весьма удивил. Моя скорость парсинга оказалась.... (барабанная дробь) в 800 раз выше.
Вот здесь есть пример моего парсинга через массив uchar.
парсинг json (и вообще парсинг) это отдельная песня ;-)
В очень большом однопоточном, скриптовом приложении работающим с криптой, возникли проблемы.
Подозрения куда только не падали, и как только всё не оптимизировалось. Засада оказалась в стороннем парсере json :-)
просто "универсальные" библиотеки заточены на универсальность, и работу с самыми заковыристыми json, а в нашей сфере таких просто нет,
да и все посылки очень короткие.
И да, парсинг текстов на MQL то ещё удовольствие :-) Ну не предназначен он для обработки текстов. То есть можно, но это @опа..
Массивы, приказы - вот стезя MQL