Мой подход. Ядро - Движок. - страница 98

 
В качестве наводки как можно сделать, посмотри на структуру zip-архива. Она состоит из простых структур и данных. Подобная структура может отлично подойти для передачи данных. Замечу, в zip архиве нет ни одной строки, что не мешает отлично отображать миниатюрную файловую систему с сотней файлов с различными именами.
 
Vasiliy Sokolov:
В качестве наводки как можно сделать, посмотри на структуру zip-архива. Она состоит из простых структур и данных. Подобная структура может отлично подойти для передачи данных. Замечу, в zip архиве нет ни одной строки, что не мешает отлично отображать миниатюрную файловую систему с сотней файлов с различными именами.

Я согласен с твоим профессиональным взглядом на задачу. Передача байтов выглядит более серьезно, чем передача строк через МТ-объекты. 

Вопрос, - насколько возможно это реализовать. 

Размер передаваемых данных и их типы, заранее неизвестны. Как прикрутить union?

 
Реter Konow:

Я согласен с твоим профессиональным взглядом на задачу. Передача байтов выглядит более серьезно, чем передача строк через МТ-объекты. 

Вопрос, - насколько возможно это реализовать. 

Размер передаваемых данных и их типы, заранее неизвестны. Как прикрутить union?

Возможно.

Изучи структуру zip подробно. Придет понимание. Рамер упакованных файлов до упаковки там неизвестен. Имена файлов могут быть самой разной длины. Количество файлов также может быть самым разным. И не смотря на это, зип представляет строготипизированный набор конечных структур ссылающихся на данные.

Когда придет понимание того, какие структуры тебе нужны будут для работы, проблем с union не возникнет, ведь union просто представление этих структур в виде байтов.

 
Vasiliy Sokolov:

Возможно.

Изучи структуру zip подробно. Придет понимание. Рамер упакованных файлов до упаковки там неизвестен. Имена файлов могут быть самой разной длины. Количество файлов также может быть самым разным. И не смотря на это, зип представляет строготипизированный набор конечных структур ссылающихся на данные.

Когда придет понимание того, какие структуры тебе нужны будут для работы, проблем с union не возникнет, ведь union просто представление этих структур в виде байтов.

Хорошо, но почему например не обойтись без юнион.

На каждом событии, советник собирает строку сообщения, включающую в себя все измененные параметры и их значения всех типов. Потом переводим эту строку в массив байтов с помощью StringToChar, и записываем в ресурс. Потом, делаем обратную распаковку. 

Изначально, я представлял именно такое решение с ресурсом. Но, необходима сборка и разбитие строки.

 
Без ресурса в твоем решение все равно не обойтись. Значит, вопрос в том, как обойтись без парсинга строки. Ты считаешь это возможным. Я, честно говоря, сомневаюсь. Но, не исключаю...
 
Реter Konow:

Хорошо, но почему например не обойтись без юнион.

На каждом событии, советник собирает строку сообщения, включающую в себя все измененные параметры и их значения всех типов. Потом переводим эту строку в массив байтов с помощью StringToChar, и записываем в ресурс. Потом, делаем обратную распаковку. 

Изначально, я представлял именно такое решение с ресурсом. Но, необходима сборка и разбитие строки.

Union - это одновременное представление структур в виде байтов или int что одно и тоже. Union как бы проецирует структуры на байтовый массив, а байтовый массив одновременно является набором структур. Если ресурс это массив int, то дополнительную процедуру по конвертации массива байтов в массив структур и обратную ей операцию делать не нужно. Это экономит время.

p.s. При этой схеме, источник сообщений не копирует данные в ресурс, он изменяет данные напрямую, а эти изменения сразу оказываются в ресурсе. Получается что вместо того что бы совершать бесконечные конвертации строк в массивы, а массивы в строку с последующим парсингом, происходит работат с данным напрямую. Данный копируются лишь получателям с помощью ResourceReadImage.

 
Vasiliy Sokolov:

Union - это одновременное представление структур в виде байтов или int что одно и тоже. Union как бы проецирует структуры на байтовый массив, а байтовый массив одновременно является набором структур. Если ресурс это массив int, то дополнительную процедуру по конвертации массива байтов в массив структур и обратную ей операцию делать не нужно. Это экономит время.

Нужно подумать... Может ты прав, и это возможно реализовать с помощью юнион. 

Например, если каждая установка значения параметра, будет конвертировать это значение в массив байтов. Точнее говоря, все пользовательские параметры, должны принадлежать юниону. Тогда, их отраженная в байтах копия будет сразу доступна для записи в ресурс.

 
Реter Konow:

Например, если каждая установка значения параметра, будет конвертировать это значение в массив байтов. Точнее говоря, все пользовательские параметры, должны принадлежать юниону. Тогда, их отраженная в байтах копия будет сразу доступна для записи в ресурс.

Да, именно, я уже ответил в ps к пред. сообщению, когда ты это писал:) Т.е мы работаем не с долгим копированием и конвертированием, а именно отображением.

 
Короче говоря, на каждом изменении значения польз. параметра, это значение нужно приводить к значению переменной из юниона и сразу сохранять в общем массиве байтов, который потом перевести в uint и записать в ресурс.
 
Vasiliy Sokolov:

Да, именно, я уже ответил в ps к пред. сообщению, когда ты это писал:) Т.е мы работаем не с долгим копированием и конвертированием, а именно отображением.

Хорошо, но как быть с текстами?

Их нужно переводить в байты через StringToChar(). Ведь через юнион вроде нельзя?