esyr | Не совсем про сериализацию, но про Delphi и RTTI или Полшага в сторону

Допустим (а такое таки иногда случается), у нас есть ряд классов, (как это обычно и бывает) потомков одного класса, для которых удобно делать вещи в духе

Entity := TEntity.Create(TSubEntity1.Create(...), TSubEntity2.Create(...), ...);
...
Entity.Free;

То есть иметь конструктор, в котором можно проинициализировать состояние объекта. Причём объект у нас сложный и может включать другие объекты. Которые, в свою очередь, могут включать третьи, и так далее. И вся эта радость создаётся в одном операторе. Удобно.

Но при таком подходе возникает проблема: а как быть с захламлением памяти? Ведь если в Java, например, есть GC, и он весь этот мусор, который появится после Entity.Free, то в Delphi (и в других old-school языках программирования, например С++) его нет, и мусор останется. При постоянном использовании подобного вида конструкторов получится неслабая такая утечка памяти.

Выход из такого положения очевиден: удалять все подобъекты при удалении корневого объекта. (Замечание в сторону: Тут, кстати, возникает следующая посторонняя проблема: подобъекты ведь могут как создаваться при создании объекта, так и быть ранее, а в конструктор передаваться лишь ссылки на них. Выходов из этой проблемы несколько: соглашение о том, что для этого объекта подобъекты создаются отдельно и нигде больше не используются; хранение флага принадлежности подобъекта к объекту, и при удалении, если этот флаг установлен, то подобъект надо удалить, иначе нет; и многие другие способы. Чаще всего используется reference counter в том или ином виде; при появлении новой ссылки на объект RefCounter увеличивается, при удалении уменьшается; когда он становится равен 0, объект убивает себя об /dev/null) Но писать отдельный деструктор для каждого нового класса обычно муторно и накладно (как бы не забыть об удалении всех подобъектов у каждого, а у каждого подобъекта могут быть ведь свои подобъекты и так далее).

Одним из возможных достаточно универсальных решений является использование RTTI. Вот, есть у нас класс TSmartDestroyableObject, у которого деструктор написан таким образом, что вызывает деструктор для всех классов-потомки TSmartDestroyableObject, которые может найти внутри себя. Собственно, деструктор выглядит так:

uses TypInfo;

...

destructor TSmartDestroyableObject.Destroy;
var
  I, Count: Integer;
  PropList: PPropList; //для хранения списка property
  SubObject : TObject;

begin
  //Получение количества property для выделение места под хранение полученной о них информации
  Count := GetTypeData(Self.ClassInfo)^.PropCount;

  if Count > 0 then
  begin
    GetMem(PropList, Count * SizeOf(Pointer));
    try
      //Получение информации о property. 
      //Первый параметр — Class Info интересующего класса, 
      //второй — указатель на кусок памяти, по которому информация будет размещена.
      //На самом деле, по переданному указателю размещаются только указатели на информацию,
      //поэтому их ещё разыменовывать надо
      GetPropInfos(Self.ClassInfo, PropList);
      for I := 0 to Count - 1 do
      begin
        //Проверка, является ли текущая property классом
        if (PropList^[I].PropType^.Kind = tkClass) then
        begin
          //Если является, то получаем ссылку на объект
          SubObject := GetObjectProp(Self, PropList^[I]);

          //И вызываем Free для него (Free вызывет Destroy, 
          //если ссылка на объект не nil).
          SubObject.Free;
        end;
      end;
    finally
      FreeMem(PropList, Count * SizeOf(Pointer));
    end;
  end;

  inherited;
end;

Тут комментарии на русском, но это исключительно для читабельности (и из-за того, что с английским я дружу плохо). Ни в коем случае не используйте неанглийские комментарии в коде.

Механизм действия сего деструктора (собственно, он уже описан выше): получаем список property, проходимся по всем, для классов вызываем Free. Если подобъекты являются потомками , и деструктор у них не переопределён (точнее, в нём вызывается деструктор для класса TSmartDestroyableObject), то они у себя сделают то же самое. И тогда, если у нас будут использоваться только объекты-потомки класса TSmartDestroyableObject, то мы сможем спокойно создавать целые их деревья одним оператором и потом спокойно удалять вызовом всего лишь одного метода Free для корневого объекта.

Ограничения: подобъекты должны быть объявены как published property объекта. Для корректного удаления целых деревьев объектов все нелистовые объекты должны быть потомками TSmartDestroyableObject.

Собственно, мне это понадобилось потому, что я таким образом создаю сообщения, которые надо сериализовать в поток. Потом подумал, что это будет полезно не только мне, и решил написать об этом.

В следующий раз будет что-нибудь про XML (Save/Load объектов, загрузка UI) и/или версионинг, смотря что доведу до презентабельного состояния первым.

Current Location: дом
Current Music: Taproot

Flat | Top-Level Comments Only

From:

pourtous.livejournal.com

"и в других old-school языках программирования, например С++) его нет, и мусор останется" -- людям, не пишущим нормальные деструкторы, надо руки отрывать.

А переложить создание деструктора на рантайм -- менее муторно конечно, но производительность упадет. Ну ты и сам понимаешь.

Тэг-то последний какой пафосный, ойоо.

From:

Не совсем про сериализацию, но про Delphi и RTTI или Полшага в сторону

Page Summary

Style Credit

Expand Cut Tags