Сохранение и загрузка настроек в текством файле

[MisterDi]

Спасибо всем участникам дискуссии. Получил достаточно информации к размышлению и реализации. Хотелось бы подвести промежуточные итоги.
1. Для быстрого хранения данных на внешнем носителе в системах с ограниченными ресурсами ИМХО оптимален метод предложенный Someone: объединение записываемых данных в некую структуру и "заворачивание" этой структуры union-om в набор байт.
2. При необходимости визуального контроля сохраняемых данных ИМХО удобен способ хранения аналогичный ini-файлам, с разбором содержимого готовым парсером.
3.Использование дополнительных идентификаторов типов данных для упрощения разбора входного потока мне кажется тоже перспективной идеей.
Тут возникал вопрос о причине выбора текстового формата. Большинство причин уже озвучены участниками обсуждения, в первую очередь - простота восприятия человеком. Железки конечно могут общаться и битовым потоком, но если нам проще воспринимать текст - пусть поднапрягутся и делают так, как нам удобнее

[OakRidge]

MisterDi
Я делаю обмен информации по GSM сетям. Тоесть, GSM модуль посылает пакет серверу.
Бинарным кодом. Мне не нравится, да таков закон. И здесь вступает в роль программист, который выводит данные на экран. Я не умею такое делать.
Да и программисту трудно выделить бит из сообщения.
Тоесть пусть длинне, да данные в ASCII понятнее. И Вам и Програмисту. Из за непоняток и экономии трафика много проектов кривыми получились.

[mike-y-k]

MisterDi, так тут много копий было поломано по поводу целесообразности затрат на текстовое представление.
Многие аспекты будут против.
Сниженное время автономной работы за счёт увеличения времени на обработку и ввод-вывод. Это в программе на C немного дополнительного кода, а в машинных командах там немало получится, ну и рост больше чем на порядок объёма данных.
Объём дополнительного кода и его сопровождение (часто выливается в параллельный проект).
Актуальность визуального контроля потока данных. Этот аспект спокойно решается в значительной части случаев отдельной утилитой. Или их набором- для автоматического контроля параметров и анализа человеком.
…

Просто я уже очень много раз наблюдал метаморфозы проектов с подобными решениями и имел немало лишней работы по разрешению возникших тупиков.

Даже в родной среде Unix (/etc, /var как минимум) затраты на модификацию кода для работы с бинарными данными в итоге дают выигрыш в автономности порядка 10-15% минимум.
Конечно при этом растёт объём кода дополнительных утилит, но тут таки автономность сначала, а все остальное - это ее обеспечение.
Тут как всегда и два конца у той палки, и бритва от монаха .
Когда создадут железо с аппаратной реализацией на уровне машинных команд преобразования представлений (на уровне printf/sprintf), тогда можно будет и вернуться к обсуждению .
Пока лишь оценка отношения общего объема данных к обрабатываемому человеком и совокупные затраты в двух моделях представления информации дадут ответ. А поскольку совсем не важно где и когда происходит преобразование в человекочитаемую форму и в точке возникновения/потребления данных преобразование формально лишено смысла, то и ответ очевиден. Это таки только форма представления.
Кстати в гонке программ/процессоров/памяти на ПК часть роста затрат принадлежит именно такому подходу. Дело Билла бессмертно .

OakRidge, а программисту по сути (в первом приближении) глубоко фиолетово используемое представление данных. Во втором же приближении отсутствие парсера для текстовых данных гораздо комфортнее. Есть структура, прочитал данные и вывел их, без дополнительного разбора и анализа переданного в тексте. Конечно можно передавать все текстом в фиксированном формате, но это уже больше на фобию похоже с неоправданными расходами на трафик .

[anton26ru]

mike-y-k, а может быть текстовый файл - решение для тестовой модели? А в дальнейшем возможны изменения и отказ от него. Для бета-версии вполне удобное решение.

[mike-y-k]

anton26ru, "нет ничего более постоянного, чем временное"(c)!!!
Или сразу ТЗ, нормальная постановка и путь к release/production без костылей, или постоянное "переделать" в 2do, откладываемое с тем же постоянством по очень объективным причинам. Практика таки говорит именно так . Да и затраты на переделку растут в прогрессии со временем…

[anton26ru]

Ну, прокрастинация - это отдельная тема.

[hacker7]

Советую всё же написать printf но имен параметров не использовать, а использовать как можно простой заведомо работающий формат, фиксированное расположение.
Имею очень боьшой опыт успешного применеия оного. Даже в системах реального времени, с доступом от десятков писателей\читателей в этот файл. Получается лучше, чем СУБД. То есть НЕ обмен сообщениями по сети, а обмен через файл чем-то типа NetBIOS.
Алфавитное представление нужно чисто для отладки и наблюдения глазами, а так можно и во внутр. предст, но неудобно

[mike-y-k]

hacker7, так опыт использования есть тут у всех. Просто ради просмотра в привычном виде придётся городить целую систему с правилами. К ТЗ на основную функцию прибавляется ТЗ на формат представления. К программированию основной функции добавляются формирование+запись и чтение+разбор текстового представления. А бинарный вариант - просто чтение/запись файла.

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

PS вариант позиционного вывода значений без имён будет ещё сложней в сопровождении и кроме текстового представления двоичных данных не даёт никакого улучшения, только ещё один поиск по таблице "значение параметра X находится в 3761 строке файла, а параметра Y - в 131" .

[H4LF]

А бинарный вариант - просто чтение/запись файла.

В общем случае - не просто (раз уж основы проектирования, а не философия). Для входящих данных (с флешь карты) тоже может потребоваться валидация - если от неправильных данных системе может стать плохо. Хотя можно сделать тяп-ляп и в продакшн, понадеявшись что ошибок чтения, записи или даже злого умысла не будет.
Ну и есть ещё мелочи вроде порядка байт и упаковки структур, о которых не стоит забывать. Может ещё какие есть, я в этом деле дилетант.
Но реализовать, конечно, заметно проще, чем с текстом, с этим я и не спорил.
А, ещё хотел спросить - акты какие-нибудь составляются, чтобы легче было найти виновных в случае чего, или только ТЗ? Но это на правах шутки)

[akegor]

Хотелось бы сказать поборникам бинарников.
Текстовый файл с "человеческой" информацией человеком воспринимается при наличии любых изменений. А вот бинарник "закатом солнца вручную" разбирать можно только хорошо зная структуру и версию этой структуры файла. Можно написать программку для ББ, которая поможет в этом нелегком деле. Но тогда ее прийдется переписывать под каждый чих.
Так что проще?
И запись в файл, и загрузка из него могут быть выполнены циклами. Много места займут только имена параметров.