Почему не все типы объектов неявно сериализуемы?
В моем ограниченном понимании объекты не просто хранятся в куче и указателях на них в стеке?
Разве вы не можете их программно перетаскивать, хранить в универсальном формате и также восстанавливать их там?
Некоторые объекты инкапсулируют ресурсы, такие как указатели файлов или сетевые сокеты, которые нельзя десериализовать в состоянии, в котором они находились, когда вы сериализовали объект, содержащий их.
Пример: вы не должны десериализовать объект, который служит аутентифицированным соединение с базой данных, поскольку для этого необходимо, вам понадобится сериализованная форма для содержат пароль открытого текста. Эта не будет хорошей практикой, потому что кто-то может завладеть сохраненным сериализованная форма. У вас также нет Идея, когда вы десериализуете, что сервер базы данных все еще работает, может доступ, аутентификация учетные данные все еще действительны и т.д.
Даже если вы рассматриваете только объекты, которые не включают состояние ОС, проблема сложнее, чем на первый взгляд. График может иметь циклы. Сущности могут ссылаться на несколько объектов верхнего уровня.
Я попытался описать универсальную библиотеку сериализации в c в предыдущем ответе и обнаружил, что есть некоторые трудные случаи.
Нет, потому что иногда у вас нет всей информации в том месте, где вы их воссоздаете. Помните, что вы не можете восстанавливать объект в том же контексте, что и у вас; это может быть другая машина или даже другой язык.
Насколько разумно было бы сериализовать объект, который содержит сетевое соединение, и отвечает за потоковое воспроизведение данных с веб-сервера?
Как насчет десериализации, как это будет работать? Если он снова откроет соединение, перезагрузите файл?
Вы правы в своих предположениях, в некотором роде.
Должно быть возможно разбить набор всех объектов в программе на группы
1) У вас есть полная информация, которая позволяет выполнить полную деконструкцию и реконструкцию объекта. Хорошим примером являются массивы чисел или строк, структуры.
2) У вас есть информация о конструкции. Вы можете восстановить объект, вызвав внешний код. Хорошим примером является файл, но он требует, чтобы ваша программа имела абстракцию файла, которая запоминает параметры построения и состояния. Мы можем, например, сохранить путь к файлу и позицию в файле. Однако реконструкция может закончиться неудачей. (Например, файл был удален или изменен)
3) У вас нет информации о конструкции, объект был как-то случайно получен.
Здесь, чтобы иметь возможность сериализовать объекты полностью, мы должны перейти от 3) до 2) к 1). Объекты в 3) могут быть атрибутами объекта типа 2) и могут быть восстановлены путем успешного восстановления объекта типа 2).
Объект типа 2, однако, должен быть восстановлен путем сериализации только информации о конструкции, которая должна быть типа 1), например номеров и строк, истинных данных.
Вся эта схема кажется дорогостоящей, поскольку, если мы хотим восстановить все состояние программы, мы должны работать с абстракциями, которые инкапсулируют объекты типа 2). И мы должны знать, что мы делаем, когда объект не может быть восстановлен. Кроме того, мы должны быть уверены, что мы не смешиваем объекты этих типов, которые мы не смешиваем в объектах типа 3 или 2, где мы собираемся собирать только объекты типа 1.
Технически любой объект в пространстве памяти может быть сериализован и сохранен на прочном носителе, таком как жесткий диск. После того, как большинство ОС загружают активную память на диск и обратно, многие из них также имеют функцию стиля спящего режима. Проблема заключается в одной из областей, например: вы создаете строковый объект в своем пространстве памяти, его сериализуете и десериализуете по своему усмотрению. Когда вы открываете файл, ОС дает вам дескриптор файла, но ОС по-прежнему владеет файловой системой, содержащей фактический файловый объект, к которому у вас есть дескриптор. С другой стороны, драйвер файловой системы должен поддерживать постоянную базу данных с файловыми дескрипторами и другими метаданными, связанными с файлами.