Чому я викликаю TRttiContext.Create () і TRttiContext.Free (), Різне, Програмування, статті

Я вважаю, що потрібно зробити перерву між статтями, для того, щоб пояснити, чому я викликаю TRttiContext.Create () і TRttiContext.Free (), хоча фактично можна цього не робити.


Так, вам не обов’язково це робити, хоча я це роблю … Чому?


Перш за все, давайте подивимося на обидві реалізації.

 
class function TRttiContext.Create: TRttiContext;
begin
Result.FContextToken := nil;
end;
procedure TRttiContext.Free;
begin
FContextToken := nil;
end;


На перший погляд тут немає нічого специфічного, значення FContextToken встановлено NIL в обох випадках.
Однак, що ж робить установка NIL для FContextToken фактично?
Ми всі прекрасно знаємо, що Delphi на поточний момент не має ніякого збирача сміття (Спеціальний код, званий складальником сміття (garbage collector), періодично звільняє пам’ять, видаляючи об’єкти, які вже не будуть затребувані додатком – тобто виробляє збірку сміття, прим. перекладача). Отже, наявність різних RTTI бібліотек, які грунтуються на об’єктах, може бути проблематичним.
У своєму коді я маю можливість робити такі круті речі як
c.GetType().GetField().FieldType.ToString


Без необхідності установки тимчасових значень для кожного об’єкта, що повертається, щоб вивільнити його.
Як це можливо без збирача сміття?
“Під капотом” ви знайдете TRttiPool, який містить всі RTTI об’єкти, які вже створені.
Коли цей пул вивільняється, всі створені в процесі викликів RTTI об’єкти також вивільняються.
Створення і знищення в цьому пулі контролюється TPoolToken, що є Інтерфейсом, який зберігається в FContextToken.
Коли TPoolToken створений і вивільнено, забезпечується підтримка PoolRefCount. І коли PoolRefCount приймає нульове значення, TRttiPool вивільняється.


І так, чому викликається. Create () і. Free ()?


Давайте почнемо с. Create ()



Це не заклик викликати даний код, пов’язаний з додатковими зусиллями. Так, безсумнівно, запис керована і, як така вона буде инициализирована, але при цьому FContextToken міститиме надмірність. Давайте розберемося … Хоча я не збираюся кожен раз створювати покажчик на TRttiContext, такий підхід дає можливість не займати передбачуваний обсяг пам’яті до тих пір, поки ви не викличете. Create.
Я так само не можу бути впевнений, що реалізація буде залишатися простою. Дуже ймовірно, що тут буде викликатися додатковий код. Збережіть мій код для себе, і в майбутньому ви зможете розкритикувати мій підхід.


Переходимо до. Free ()


Я хочу залишити своє розміщення пам’яті (memory foot print) чистим. Безсумнівно, коли мінлива TRttiContext виходить за рамки звичайного поведінки це відбудеться.
На самому початку своїх дослідів з RTTI, я ненароком отримав access violation в деструкції спадкоємця TCustomAttribute. При виклику. Free () було легше побачити, в чому полягала проблема, ніж при отриманні цього події після деструкції об’єкта, в якому TRttiContext був оголошений як поле.
І що б відсікти тривіальні коментарі … Так, я знаю, що документація свідчить, що вам не потрібно викликати. Free (). Так же передбачається, що дана технологія важлива, тому що вона забезпечує те, що RTTI об’єкти є кешуються і використовуються повторно, це буде справедливо для TRttiContext, описаного як глобальна змінна, що мені здається дуже поганою ідеєю.
Я думаю, що замість цього вам слід зберігати TRttiContext до тих пір, поки вам це потрібно, але вивільняти його в коректне час.
Коротенько … Я вважаю, що це особиста справа кожного.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*