C/C++ Глобальная структура данных программы

[jur]

Привет!

Я понимаю, тема озаглавлена как-то коряво и неточно. Поэтому подробно распишу, что именно я имею ввиду.

С довольно давних времен я применяю некую глобальную структуру, в которой содержатся разные переменные моего приложения. Например, в этой структуре лежит название клиники, имя пациента, текущий режим работы прибора, текущая глубина сканирования (причем, в двух видах: определенная доктором и реальная, вычисленная из "железных" возможностей), текущий выбранный датчик со своей кучей параметров и миллион других вещей, нужных для работы прибора. На первых порах все было прекрасно. Обращаешься к этой структуре и получаешь нужное значение. Очень быстро, можно работать даже в критических по времени потоках.

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

А все усугубляется еще и тем, что нужно запоминать все текущие параметры (т.е. эту самую глобальную структуру) вместе с запоминанием результата обследования пациента. Т.е. доктор посмотрел пациента, сохранил в файле результаты обследования. Через некоторое время он хочет снова взглянуть на эти результаты. А в приборе изменилось ПО. Новая глобальная структура уже не такая, какая была в момент сохранения.

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

Поделитесь, пожалуйста, своим опытом в решении подобной проблемы.

[Sla]

Потому что изначально была неверно построена объектная модель.

Если на пальцах.. то

Объект датчик:
величина
тип


Объект прибор
Коллекция Объектов датчик

Объект пациент

Объект врач

Объект клиника


И.т.д.

Каждый объект имеет свои конструкторы, сеттеры и гетеры
И, как универсальные методы, так и уникальные.

[Dale]

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

IMHO если реализовать рекомендацию Sla плюс добавить сериализацию объектов в XML, это если и не решит проблему полностью, то во всяком случае очень сильно ее смягчит. По мере развития системы можно будет добавлять новые элементы данных, при этом не конфликтуя с прежними форматами.

[jur]

Каждый объект имеет свои конструкторы, сеттеры и гетеры
И, как универсальные методы, так и уникальные.

Объекты я сделал. Точнее, несколько структур, соответствующих объектам. Как с этим делом обращаться - вполне понятно. Непонятно, как сохранить данные объекта в файл, чтобы потом их можно было из этого файла извлечь. Ведь если сохранять данные в двоичном виде, т.е. просто сохранить структуру в файл как есть, то при ее изменении прочитать старую структуру уже не получится. Мне представляется, что нет другого пути, как сохранять данные в виде пар: <идентификатор> - <значение>. Или другой путь все-же есть?

IMHO если реализовать рекомендацию Sla плюс добавить сериализацию объектов в XML, это если и не решит проблему полностью, то во всяком случае очень сильно ее смягчит. По мере развития системы можно будет добавлять новые элементы данных, при этом не конфликтуя с прежними форматами.

Звучит очень заманчиво :-) "Спинным мозгом чувствую..." (С) как-то так и нужно поступить. Только я эту сериализацию объектов в XML никогда раньше не делал, не приходилось сталкиваться. К тому же, в названии темы я указал "C/C++", т.е. хотелось бы не использовать прибамбасы .NET, если этого можно избежать. Наверное это возможно?

P.S. Нашел статью "FAQ:STL:C++ сериализация данных" на Википедии нашего клуба. Интересно, хотя и малопонятно. Попытаюсь разобраться...

[Sla]

xml - грубо, текстовый файл, имеющий свой язык разметки...
Т.е. ничего сложного

Сохранять можно всю структуру, точно так же и восстанавливать...

Опять же на пальцах

Код:

<клиника>
  <врач отделение="отделение">
     <fio>fio</fio>
  </врач>
  <врач отделение="отделение2" fio="fio">
     <пациент id="id1">
     </пациент>
     <пациент id="id2">
     </пациент>
  </врач>
  <пациент id="id1">
  </пациент>
  <пациент id="id1">
  </пациент>
</клиника>

Приблизительно...

Т.е. загрузка xml документа, анализ вершин ...

[Dale]

К ранее сказанному могу добавить лишь, что, поскольку в формате XML действительно нет ничего с виду сложного, очень важно не поддаться соблазну писать сериализацию самостоятельно. Ведь с готовым генератором/парсером XML нужно еще разобраться, а тут сразу сел - и через полчаса уже что-то рабочее нарисовалось (сам когда-то грешил подобным). Изучение готовой библиотеки, будь то SAX или DOM, сэкономит гораздо больше времени, чем займет само по себе.

хотелось бы не использовать прибамбасы .NET, если этого можно избежать. Наверное это возможно?

В принципе возможно, конечно, на .NET свет клином отнюдь не сошелся (по крайней мере пока). Но я бы не рекомендовал делать это самоцелью.

Если есть объективная потребность избежать применения .NET (например, необходимость портирования кода на платформу, для которой .NET не реализована), то сам бог велел, как говорится. Если лишь субъективное неприятие - рекомендую его пересмотреть (как .NET-чик с более чем десятилетним стажем). Эту платформу разрабатывали отнюдь не враги рода человеческого с целью сделать и без того нелегкую жизнь программистов вовсе невыносимой, а скорее наоборот. Очень многие стандартно-повседневные задачи решаются в ней очень просто, а сериализация состояния класса с последующим его восстановлением как раз к таким задачам и относится.

[Dale]

P.S. Еще мысль вдогонку по поводу

Мне представляется, что нет другого пути, как сохранять данные в виде пар: <идентификатор> - <значение>. Или другой путь все-же есть?

Посмотрите еще как вариант язык YAML. Возможно, понравится больше, чем XML. Лично я его предпочитаю для хранения не слишком сложных структур данных, и для чтения человеком он мне кажется более удобным.

[Aether]

Почему нельзя каждый параметр сохранять в свой файл?
То есть: файл №1 - содержит имена объектов и порядковые номера к ним,
              файл №2 - содержит значения параметра (1) по порядку от первого номера к последнему, в таком виде
, например, 80бит вещественное х 8 раз, +1 байт на актуальное присутствие параметра - записи с 1 по 8, далее записи 9...
              файл №3 - содержит значения параметра (2) по порядку от первого номера к последнему, в таком виде
, например, 32бит целое без знака х 8 раз, +1 байт на актуальное присутствие параметра...
Если идёт запись не параметра, а потока, то каждый поток нужно сбросить в свой файл, а ссылку на него дать в
файле параметров, например, файл №4.
Проблема добавления новых параметров будет решена на уровне файловой системы.
Имеет это право на жизнь?

[Finch]

Aether, Ключевое слово "Медицинское оборудование". Насколько я знаю, действует стандарт DICAM. Если его не соблюдать, то будут проблемы с совместимостью с другим оборудованием и другим ПО.

[Aether]

Напрашивается простое решение: использовать что-то похожее на DICOM.

Aether, Ключевое слово "Медицинское оборудование". Насколько я знаю, действует стандарт DICAM. Если его не соблюдать, то будут проблемы с совместимостью с другим оборудованием и другим ПО.

Как видно, у ТСа DICAM не организован. Сам о нём ничего не знаю - не сталкивался. Хотя, если это стандарт, то лучше автору его изучить, так как "левое", но работающее, решение сейчас не будет иметь перспективы.

[Dale]

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

Доводы в пользу единого файла конфигурации:

1. Можно иметь несколько вариантов конфигураций (например, с разными калибровками, или разными наборами датчиков и т.д.) и при запуске программы указать нужный файл. В случае, когда таких файлов великое множество, достаточно трудно перечислить все, имеющие отношение к делу, и увязать файлы с параметрами.

2. Проще проверить целостность данных (например, синтаксический контроль XML или YAML, подсчет контрольной суммы и т.п.).

[Sla]

очень важно не поддаться соблазну писать сериализацию самостоятельно. Ведь с готовым генератором/парсером XML нужно еще разобраться, а тут сразу сел - и через полчаса уже что-то рабочее нарисовалось

100%
Я показал простоту реализации xml

А писать свой парсер, анализатор, валидатор... - только на этапе учебы.

Также рекомендую ознакомиться с XSLT

Это позволит создавать и работать с циклическими (повторяющимися) структурами.

[Sla]

Насколько я знаю, действует стандарт DICAM

DICOM

И сюда смотреть обязательно.