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