Сумісність структур даних

Для коректної роботи програм читання та запису об’єктів (таких як 26.7 та 26.7а) повинні мати на увазі один клас об’єктів. Наприклад, об’єкти класу person мають довжину рівно 82 байти, з яких 80 відведено під ім’я людини, 2 – під вік в форматі short. Якби програми не знали довжини полів, то одна з них не змогла б коректно прочитати з файлу те, що записала інші.

Попри те, що класи person в двох попередніх програмах мають одинакові компонентні дані, в них можуть бути зовсім інші методи. Скажімо, в першій програмі є функція getData(), в другій – showData(). Неістотно, які методи використовуються в класах – вони в файл разом з даними не записуються. Це для даних важливим є спільний формат, а розбіжності в методах до жодних наслідків не призводять. Це твердження справедливе лише для звичайних класів, в яких не використовуються віртуальні функції.

Якщо ви пишете в файл і читаєте об’єкти похідних класів, необхідно дотримуватися великої обережності. В цих об’єктах є загадкове число, що ставиться перед початком їх області даних в пам’яті. Воно допомагає ідентифікувати клас об’єкту при використанні віртуальних функцій. Коли ми записуємо об’єкт в файл, це число записується разом з іншими даними. Якщо змінюються методи класу, ідентифікатор теж змінюється. Якщо в класі є віртуальні функції, то при читанні об’єкту з тими ж даними, але іншими методами, виникнуть значні труднощі. Висновок: клас, що використовується для читання об’єкту, повинен бути ідентичний з класом, що використовується для його запису.

Можна навіть не намагатися здійснити дисковий ввід-вивід об’єктів, компонентами яких є вказівники. Легко здогадатися, що значення вказівників не будуть коректними при читанні об’єкту в іншу область пам’яті.