Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: C/C++ Глобальная структура данных программы  (Прочитано 13473 раз)
0 Пользователей и 1 Гость смотрят эту тему.
jur
Помогающий

lt
Offline Offline

« : 12-06-2014 16:36 » 


Привет!

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

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

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

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

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

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


Записан

MPEG-4 - в массы!
Sla
Модератор

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 12-06-2014 16:49 » 

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

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

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


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

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

Объект врач

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


И.т.д.

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 12-06-2014 17:33 » 

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

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
jur
Помогающий

lt
Offline Offline

« Ответ #3 : 13-06-2014 06:03 » new

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

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

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

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

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


« Последнее редактирование: 13-06-2014 06:29 от jur » Записан

MPEG-4 - в массы!
Sla
Модератор

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 13-06-2014 12:23 » 

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

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

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

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

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

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 13-06-2014 14:13 » 

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

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

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

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #6 : 13-06-2014 14:21 » 

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

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Специалист

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 14-06-2014 11:38 » 

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

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #8 : 14-06-2014 14:32 » 

Aether, Ключевое слово "Медицинское оборудование". Насколько я знаю, действует стандарт DICAM. Если его не соблюдать, то будут проблемы с совместимостью с другим оборудованием и другим ПО.
« Последнее редактирование: 14-06-2014 15:04 от Finch » Записан

Не будите спашяго дракона.
             Джаффар (Коша)
Aether
Специалист

ru
Offline Offline
Пол: Мужской

« Ответ #9 : 14-06-2014 17:51 » 

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

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

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #10 : 14-06-2014 17:58 » 

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

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

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

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Sla
Модератор

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #11 : 16-06-2014 20:00 » 

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

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

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

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Sla
Модератор

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #12 : 16-06-2014 20:03 » 

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

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines