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

[H4LF]

H4LF, чувак - ты посты чтоль набиваешь??? ничо толкового я ни капли в твоих постах не увидел

Содержательнее этого Вашего поста я на всём форуме не видел. Спасибо за замечание, я буду стараться над увеличением своей толковости. Всего доброго.

[akegor]

самое неприятное в этой ситуации - дублирование переменных и указателей на них.

MisterDi, насколько я понимаю, текстовый файл нужен для человека (для разборок). Человек способен в нем отыскать то, что его интересует.
Дальше. Сохраняет настройки конкретный тип устройства и эти настройки актуальны только для него. Поэтому чисто формально по таблице и действовать на запись и на считывание. Таблица имен настроек и таблица (ну или списки) переменных. Преобразование - стандартная функция, в которую передаются указатели на имя и на переменную. Всего несколько шаблонов. Сгруппировать по типам и циклом их, циклом...
Честно, не понял, в чем затык?

[mike-y-k]

Вопрос о необходимости именно текстового представления.
Если таки будет человек посреди - тут можно и заморочиться.
Но двоичная выгрузка данных в достаточно простом формате:
длина, дескриптор, данные позволит весьма сильно сократить код в устройстве за счёт преобразования данных, да и на производительности/реакции выиграть.
В заголовке данных можно предусмотреть поле с версией для разбора этих данных и исключения коллизий форматов.

А сами по себе алгоритмы и код для разбора (при ещё сохранившемся желании таки работать с текстом) стоит поискать в библиотеках Unix.

[anton26ru]

Готового решения не знаю, но алгоритм простой.

Перед данными пишется идентификатор, указывающий на тип данных. Чтобы был уникальным и не путался с данными, можно сделать двух-трехсимвольным. Скажем, #!n, где n указывает тип данных. Тогда и разделители не нужны. Пишется всё подряд. При считывании, всё что от идентификатора до идентификатора - данные.

Хотя... можно и перевод строки делать.

[oleg110592]

раньше, например на PC, настройки сохраняли в ini файл, может подойдет простой парсер:
https://github.com/benhoyt/inih

[Someone]

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

А зачем текстовый? Какие-бы не были переменные, в памяти они всё равно хранятся в виде байт. А посему ничто не мешает определить юнион, в который входят все переменные, обёрнутые структурой, и массив байт, по длине этих переменных. Записав или считав этот массив автоматически запишешь или прочитаешь все переменные, вне зависимости от их типа, длины, расположения в памяти (биг или литл эндиан).

[Someone]

У ТС вполне ясная и определённая задача - сохранять настройки в текстовый файл и загружать из текстового же файла.

Найн. Задача сохранять и загружать настройки в файл. Что вовсе не обязательно текстовый.

[Someone]

Типа так:

typedef union
{
	unsigned char bytes[10];         // массив байт

	struct
	{
		struct
		{
			unsigned char DeviceCmd;        // 0x0000 команда извещателю
			unsigned char DeviceStatus;     // 0x0001 состояние извещателя
			unsigned char SelfTestInterval; // 0x0002 интервал самотестирования, минут
			unsigned char AlarmPeriod;	// 0x0003 длительность анализируемого периода для тревог, секеунд
			unsigned char DeviceAdress;     // 0x0004 адрес устройства в сетях модбас
			unsigned char AlarmCountIR;	// 0x0005 предел счётчика ИК-тревог, превышение - тревога
			unsigned char AlarmCountUV;	// 0x0006 предел счётчика УФ-тревог, превышение - тревога
		} set;
		
		struct
		{
			unsigned char AlarmCountIR;     // счётчик тревог по УФ каналу
			unsigned char AlarmCountUV;     // счётчик тревог по ИК каналу
			unsigned char AlarmPeriod;      // период тревог
		} var;
	};

} TData;

[Someone]

Можно обойтись и без массива. Тут главное все переменные в структуре чтоб были. А после можно и указатель установить на начало структуры, писать и читать по байту, пока всю структуру не запишешь/считаешь.

[mike-y-k]

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