Мой подход. Ядро - Движок. - страница 98
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В качестве наводки как можно сделать, посмотри на структуру zip-архива. Она состоит из простых структур и данных. Подобная структура может отлично подойти для передачи данных. Замечу, в zip архиве нет ни одной строки, что не мешает отлично отображать миниатюрную файловую систему с сотней файлов с различными именами.
Я согласен с твоим профессиональным взглядом на задачу. Передача байтов выглядит более серьезно, чем передача строк через МТ-объекты.
Вопрос, - насколько возможно это реализовать.
Размер передаваемых данных и их типы, заранее неизвестны. Как прикрутить union?
Я согласен с твоим профессиональным взглядом на задачу. Передача байтов выглядит более серьезно, чем передача строк через МТ-объекты.
Вопрос, - насколько возможно это реализовать.
Размер передаваемых данных и их типы, заранее неизвестны. Как прикрутить union?
Возможно.
Изучи структуру zip подробно. Придет понимание. Рамер упакованных файлов до упаковки там неизвестен. Имена файлов могут быть самой разной длины. Количество файлов также может быть самым разным. И не смотря на это, зип представляет строготипизированный набор конечных структур ссылающихся на данные.
Когда придет понимание того, какие структуры тебе нужны будут для работы, проблем с union не возникнет, ведь union просто представление этих структур в виде байтов.
Возможно.
Изучи структуру zip подробно. Придет понимание. Рамер упакованных файлов до упаковки там неизвестен. Имена файлов могут быть самой разной длины. Количество файлов также может быть самым разным. И не смотря на это, зип представляет строготипизированный набор конечных структур ссылающихся на данные.
Когда придет понимание того, какие структуры тебе нужны будут для работы, проблем с union не возникнет, ведь union просто представление этих структур в виде байтов.
Хорошо, но почему например не обойтись без юнион.
На каждом событии, советник собирает строку сообщения, включающую в себя все измененные параметры и их значения всех типов. Потом переводим эту строку в массив байтов с помощью StringToChar, и записываем в ресурс. Потом, делаем обратную распаковку.
Изначально, я представлял именно такое решение с ресурсом. Но, необходима сборка и разбитие строки.
Хорошо, но почему например не обойтись без юнион.
На каждом событии, советник собирает строку сообщения, включающую в себя все измененные параметры и их значения всех типов. Потом переводим эту строку в массив байтов с помощью StringToChar, и записываем в ресурс. Потом, делаем обратную распаковку.
Изначально, я представлял именно такое решение с ресурсом. Но, необходима сборка и разбитие строки.
Union - это одновременное представление структур в виде байтов или int что одно и тоже. Union как бы проецирует структуры на байтовый массив, а байтовый массив одновременно является набором структур. Если ресурс это массив int, то дополнительную процедуру по конвертации массива байтов в массив структур и обратную ей операцию делать не нужно. Это экономит время.
p.s. При этой схеме, источник сообщений не копирует данные в ресурс, он изменяет данные напрямую, а эти изменения сразу оказываются в ресурсе. Получается что вместо того что бы совершать бесконечные конвертации строк в массивы, а массивы в строку с последующим парсингом, происходит работат с данным напрямую. Данный копируются лишь получателям с помощью ResourceReadImage.
Union - это одновременное представление структур в виде байтов или int что одно и тоже. Union как бы проецирует структуры на байтовый массив, а байтовый массив одновременно является набором структур. Если ресурс это массив int, то дополнительную процедуру по конвертации массива байтов в массив структур и обратную ей операцию делать не нужно. Это экономит время.
Нужно подумать... Может ты прав, и это возможно реализовать с помощью юнион.
Например, если каждая установка значения параметра, будет конвертировать это значение в массив байтов. Точнее говоря, все пользовательские параметры, должны принадлежать юниону. Тогда, их отраженная в байтах копия будет сразу доступна для записи в ресурс.
Например, если каждая установка значения параметра, будет конвертировать это значение в массив байтов. Точнее говоря, все пользовательские параметры, должны принадлежать юниону. Тогда, их отраженная в байтах копия будет сразу доступна для записи в ресурс.
Да, именно, я уже ответил в ps к пред. сообщению, когда ты это писал:) Т.е мы работаем не с долгим копированием и конвертированием, а именно отображением.
Да, именно, я уже ответил в ps к пред. сообщению, когда ты это писал:) Т.е мы работаем не с долгим копированием и конвертированием, а именно отображением.
Хорошо, но как быть с текстами?
Их нужно переводить в байты через StringToChar(). Ведь через юнион вроде нельзя?