The process of loading an archive may result in the creation of new objects. That
same process may throw an exception at some point. In order to prevent memory leaks
and invalid pointers, these situations must be considered. Unfortunately, there is
no simple universal solution to this problem. The manner of addressing this must
depend on the design of the data structures to be serialized. Below, we discuss
varying scenarios in increasing order of difficulty. This discussion presumes that
the class member functions are exception safe before considering serialization.
That is, the destructor could be called at anytime without referencing
an invalid pointer, or creating a memory leak.
class contains no pointers
No problem here.
Класс содержит толькоВладелецУказатели
Отсюда мы должны провести различие между указателями, используемыми для управления кучным хранилищем, принадлежащимиуказателям, и указателями, используемыми для обозначения связанных объектов, на которые ссылаютсяуказатели. Программы, содержащие указатели, принадлежащие, должны содержать код для удаления этих объектов и возврата размещенного хранилища в кучу. Программы, содержащие указатели, на которые делается ссылка, должны быть разработаны таким образом, чтобы такие указатели, на которые делается ссылка, не удалялись после того, как указанный объект был уничтожен и его хранилище было возвращено в кучу. Если же он находится только в одном месте, то он должен быть.
Функция нагрузки улавливает любые исключения, возникающие между временем создания объекта и его указателем. Если во время чтения архива происходит исключение, созданный объект удаляется, а десериализованный указатель устанавливается в NULL. Это гарантирует отсутствие утечек памяти. Тот факт, что нет других копий этого указателя, гарантирует, что никакие указатели не останутся недействительными. Деструктор объекта должен иметь возможность без проблем удалять любые другие существующие объекты обычным способом.test_delete_pointer.cppиллюстрирует этот случай.
Класс содержит один или болееСсылкаУказатели
Эту ситуацию можно подразделить на два случая.
Принадлежащиеуказатели всегда сериализуются доСсылкаУказатели
Отслеживание объектов гарантирует, что никакие новые объекты не будут созданы путем загрузки указателя, на который делается ссылка. Если произойдет исключение, указателис ссылкамине нужно будет удалять, чтобы не было утечек памяти. Деструктор этого класса не будет пытаться удалить эти указатели, поэтому не будет проблем с болтающимися ссылками.Собственныеуказатели обрабатываются точно так, как описано выше.
Класс содержит,, которые могут быть созданы с помощью
Еслиссылочныйуказатель загружается до его соответствующегопринадлежащегоуказателя, то объект распределяется по куче. В некоторых случаях неизвестно, какие указатели были созданы их владельцами и какие были созданы функцией нагрузки. Чтобы решить эту проблему:
Исключения из ловушки с блоком<try/catch>.
В части улова вызовите функцию архива<delete_created_pointers()>, чтобы удалить любые указатели, созданные загрузкой класса. Без других действий объекты, созданные таким образом, окажутся утечками памяти, поскольку они не считаютсяпринадлежащимиуказателями и, следовательно, не уничтожаются.
Деструктор объекта не будет пытаться удалитьссылкиуказатели, поэтому любые висящие ссылки не причинят вреда.
Ситуации, не охваченные выше, являются указателями, для которых классификации, на которые ссылаютсяи, принадлежащие, не применимы. Это может произойти, когда указатели создаются одним классом, но потребляются и удаляются другим. Они могут быть рассмотрены с помощью специального анализа, аналогичного вышеупомянутому. По мере того, как ситуация становится более сложной, это становится более трудным и подверженным ошибкам. В конце концов, это должно быть решено путем построения управления кучей в сам указатель - то есть в<boost::shared_ptr>. Библиотека включает в себя сериализацию<boost::shared_ptr>. Как упоминалось ранее, это потребовало небольшого изменения в одном из файлов реализации<boost::shared_ptr>, чтобы разрешить доступ к системе сериализации.
