Как перенести структуру в бинарный файл что бы он мог его прочитать без повреждения файла?

Question

[armadillo-cld]

Всем привет.
Есть такой код:

// Объявляю структуру
struct Settings {
int year;
char name[52];
};
..
long int filesize = 92672; // Приходиться контролировать размер файла =(
Settings s;
int fize = MAX_PATH;
char *filename = new char[size];
GetModuleFileNameA(NULL, filename, size); // Получаю путь к себе

ifstream file(filename, ios::binary);
file.seekg(filesize); // Ставлю указатель на конец файла
file.read((char*)&data, sizeof(Settings)); // Читаю внедрённую структуру
file.close(); // Закрываю

Это сам бинарный файл.
А вот файл, который внедряет структуру:

// Объявляю структуру 
struct Settings {
int year;
char name[52];
}
..
// Инициализирую переменные
Settings s;
s.year = 12;
strcpy(s.name, "Alesha");

// Внедряю
ifstream binaryfile("person.exe", ios::binary);
ofstream injected("person created.exe", ios::binary);

injected << binaryfile.stdbuf();
binaryfile.close();

injected.write((char*)&s, sizeof(Settings));
injected.close();

Но в этом методе есть минусы:
1. Приходиться вводить размер файла в байтах, а если ввести большие данные - размер файла станет больше введённого и будет выводиться мусор.
2. Не рабочий. Почему-то если я добавляю новых переменных. Например "char car[52];" и т.п, то выводиться либо пустые строки, либо мусор в виде *!@(EU.

Что делать? Есть какой то "кроссплатформенный" способ? Нужно перенести данные в бинарный файл как-то.

Answer 1

[Mercury13]

Начнём с 2. Структуры, используемые как формат файла, применяй в прикладном коде с большой осторожностью. Если хочешь, чтобы формат расширялся, придумай простенький блочный формат.
Для 1 — приходится использовать какую-то сигнатуру и находить её в файле.
Например: после собственно EXE-файла идут данные, потом сигнатура и положение данных в файле. Сигнатуры нет или смещение странное — значит, просто приклеивай всю эту дрянь в конец файла. Сигнатура есть и смещение правдоподобное — идём по указанному смещению, пишем новые данные вместе с новой сигнатурой, а потом усекаем файл (на случай, если старые данные были длиннее).
На этом принципе, кстати, основаны самоизвлекающиеся архивы RAR и RARJPEG — только сигнатура в начале, а не в конце RAR-данных.
Ещё нужно проверить, в какой кодировке ifstream принимает данные — UTF-8 или Win-1251. Начиная с Си++17 появилась поддержка юникодных имён файлов, но я с нею не работал.

Comments

[armadillo-cld]

Спасибо огромное!!!
Моя ошибка была в том, что я брал размер файла в байтах, и читал, т.е по сути я пропускал внедрённый текст. Решил сделать так:

long int filesize = GetFileSize(string(filename)) - sizeof(s.name) - sizeof(s.car) - sizeof(int);

Т.е, я брал размер файла, отнимал размер структуры и читал с начала структуры.
И всё получилось!
Читается идеально.

[maaGames]

armadillo-cld, Ничего идеального. Структура имеет неопределённый размер в байтах. В зависимости от компилятора и его настроек размер структуры в байтах может поменяться и сломается запись/чтение. Если хочется всю структуру как бинарный дамп памяти сохранять/считывать, то при определении структуры надо задать выравнивание памяти. В данном случае, выравнивание на 1 или 4 байта задать. При условии, что int - 4 байта.

[armadillo-cld]

maaGames, Как сделать выравнивание памяти?

[maaGames]

armadillo-cld, зависит от конкретного компилятора. Вот здесь и подробности и примеры кода https://habr.com/ru/post/142662/

[armadillo-cld]

maaGames, Т.е если скомпилировать мою программу другим компилятором и\или изменить настройки компилятора - то метод не будет работать? Ну я все свои программы компилияю на MSVC++, так что не думаю что для меня это проблема...

[maaGames]

armadillo-cld, лучше сразу писать правильно, чтобы не привыкать к потенциально опасному коду. В зависимости от выравнивания, между полями могут быть добавлены "пустые" байты, чтобы адрес следующего поля был выровнен по определённому адресу. Многие оптимизации требуют выравнивание по 16 байт, напрмиер, чтобы максимально эффективно всякие SSE использовать. 32 битные на 4 байта выравниваются, как минимум. Т.е. в твоём случае нет гарантии, что структура занимает ровно 56 байт. Поменяешь опции оптимизации или обновишь компилятор, сменишь х86 на х64, поменяешь настройки ивсё, будет сохраняться уже не 56 байт и все сохранённые файлы поломаются. Поэтому, если сохраняешь всю структуру как raw-bytes, то обязательно указывай pragma pack.

[armadillo-cld]

maaGames, Я немного почитал статью, что вы скинули. Т.е мне всего лишь нужно добавить
#pragma pack(push, 1) // 1 или 4
И всё будет нормально?

[maaGames]

armadillo-cld, Ну да :)

[armadillo-cld]

maaGames, Здравстуйте. У меня новый вопрос появился. А где нужно ставить #pragma pack(push, 1) - 1, а где 2, 3, 4? Я просто не совсем понимаю. Вот допустим у меня структура:

int age;
bool alive;
char name[52];
char lastname[52];

Если я сделаю push, 1, то всё будет нормально? И разницы никакой не будет, если поставить push, 2, 3,4?

[maaGames]

armadillo-cld, prama pack задаёт максимально допустимое выравнивание, т.е. смещение адресов данных-членов будет кратно заданному значению. С pack 1 всё будет нормально во всех случаях, но это может очень серьёзно отразиться на производительности. Для всяких SSE делается выравнивание по 16 байтам вообще, чтобы эффективн к ним обращаться.
В общем случае, данные-члены желательно располагать в порядке уменьшения размера типа данных. Т.е. сперва все double, потом int, short, char. В этом случае структура будет наиболее компактной и эффективно работающей, даже без pragma pack.
Напрмиер, есть две структуры (1){double, char} и (2){char,double}. В сависимости от настроек компиляции и ptagma pack, из размер может быть (1)=9 байт, (2)=16 байт. Или обе по 9 байт. или обе по 16 байт. Или что-то между 9 и 16 байт. При большо желании даже 32 байта может быть...
А вот чтобы об этом всём не думать, не нужно сохранять структуру как дамп памяти, а нужно сохранять каждое поле по очереди. Да, это больше писанины, зато подводных камней намного меньше и можно сделать поддержку разных версий этой структуры.