Роман М. писал(а):
Пётр Кушнир писал(а):
Не, суть именно в том, что это структура типа массива. Нужно хранение в массиве всяких структур. Допустим оно будет.
А далее интересно, как там должно быть, например, с обработкой массива, который того и гляди изменится.
Тогда можно взять на вооружение метод наподобие тегирования структур в компиляторе КП.
Вместе с данными будут отправляться также служебные данные. Каждому тегу соответствует свой тип данных. Перед отправкой структуры данных подписчикам она сначала описывается с помощью тегов. Таким образом, приёмник будет знать в каком формате эти данные пришли и как их раскодировать.
Допускается ли применение вложенных структур?
Не, ничего никуда не будет отправляться. Представьте себе что у двух ББ есть общая область памяти, и когда вы в одном ББ делаете SYSTEM.PUT, то в другом вы делаете SYSTEM.GET и получаете записанное ранее значение. Над этой памятью оформлена реализация абстракции Files.File. То есть у вас есть общий файл. Теперь надо в этот файл писать байты так, чтобы на той стороне поняли смысл этих байтов.
На первый взгляд, Stores это один из вариантов такого понятного объекта. И задача состоит в том, чтобы реализовать такую параллельную структуру данных, которой
просто пользоваться, примерно как массивом или коллекцией.
Для этого нужна коллекция, которая не будет использовать указатели и прочее, но работать будет как обычная коллекция. Вот я и спросил.
Илья Ермаков писал(а):
Я когда-то делал тупо "двоичный дамп" записи в Files.File.
Где-то даже публиковал на форуме, но не ищется!!
Что несложно сделать через Kernel и Type.size.
Этот вариант хороший и быстрый, но не позволит подключать к общей памяти другие платформы, отличные от ББ, тот же GPCP. Хотя, может это и не нужно.