Хороший способ хранения самых разнообразных конструкций, размеры которых также варьируются? - PullRequest
Новая
       10

Хороший способ хранения самых разнообразных конструкций, размеры которых также варьируются?

2 голосов
/ 21 сентября 2010

Название немного сбивает с толку, поэтому я объясню немного больше на примерах. Просто примечание: я анализирую формат файла. Скажем, у нас есть такая структура: 

struct example
{
   typeA a;
   typeB b;
   typeX x;
   typeY y;
   typeZ z;
};

Пока все хорошо. Теперь проблема в том, что typeX, typeY и typeZ могут различаться по размеру. В зависимости от флагов в заголовке файла (метаданных) они могут быть размером два или четыре байта. Другое дело, что есть еще несколько таких структур (около 40). Каждый из них использует typeX, typeY, typeZ. Некоторые из них все, некоторые только один или два. И, наконец, большинство из них являются необязательными, поэтому может использоваться только четыре или пять структур, или 20 или 30 ...

Я хотел бы знать, есть ли у кого-нибудь идея, как хранить такой изменяющийся набор данных. Я думал об использовании шаблонов, но не знаю, правильно ли это.

РЕДАКТИРОВАТЬ: уточнить больше: память не является большой проблемой, поэтому я, вероятно, могу позволить себе тратить немного места. Если typeX составляет четыре байта, то это так для всех структур. Однако они не синхронизированы, поэтому typeX может быть 4 байта, typeZ может быть 2. Большинство структур может использоваться несколько раз, поэтому может быть 50 структур example1, 10 структур example2 и т. Д.

Ответы [ 2 ]

2 голосов
/ 21 сентября 2010

Для меня проблема не столько в распределении некоторого пространства, в принципе мы можем сделать это: 

byte *pA = new byte[the size this time];

, а в том, что вы делаете с этими объектами типа A.Что возвращает 

pA->getValue()

?Намерение, что это всегда, скажем, 32-битное число?Или у нас действительно 

pA->get16bitValue()

в некоторых случаях и 

pA->get32bitValue()

в других?

Я бы сначала искал способ инкапсулировать это различие, и способ сделать это во многом зависит от того, как вы используете значения.Проблема хранения, вероятно, решаема с помощью небольшого динамического распределения.Это фактическое поведение типа А, которое я считаю хитрым.

1 голос
/ 21 сентября 2010

Один из факторов, который вы не упомянули, так как вы анализируете файл, это то, предназначено ли программное обеспечение как независимое от процессора.Некоторые процессоры имеют младший порядок, что означает, что элемент данных хранится с младшим байтом первым и старшим байтом последним.Другие процессоры имеют байтовый порядок, а порядок следования байтов - наоборот.Когда вы анализируете файл, вы должны принять это во внимание, если файл мог быть записан с использованием процессора с противоположным порядком байтов.Надежный способ сделать это - определить порядок байтов, требуемый форматом файла, а затем прочитать файл по одному байту за раз и построить данные с использованием соответствующих операторов сдвига, например, 

intVal = (buffer[0] << 24) | (buffer[1] << 16) | (buffer[2] << 8) | buffer[3];

Итак, вы видите, чточтение файла непосредственно в структуру, вероятно, не является хорошей идеей.

Вы действительно должны рассматривать файл как поток (что он есть) и определять потоковые операции для передачи данных в ваши структуры внутренней памяти одним элементом.за один раз.

Если вы примете это, то формат файла будет отделен от вашей внутренней структуры памяти.Затем вы можете хранить данные внутри, как вам нравится.В вашем случае это звучит как идеальное приложение для полиморфизма.Вы можете объявить подкласс для каждого варианта typeX / Y / Z.Или вы можете использовать один класс и позволить ему выделять переменное количество памяти в своем конструкторе.Все зависит от ваших обстоятельств.Ключ состоит в том, чтобы отделить формат файла от вашей внутренней структуры памяти.

...