Bonart Oct 21 2009 at 22:45

Об «очевидном» и полезном или создание и уничтожение объектов Delphi

2 min

7.1K

Delphi*

+18

Comments 44

megalol Oct 21 2009 at 22:50

А еще есть замечательные методы BeforeDestruction и AfterConstruction

Bonart Oct 22 2009 at 14:38

Есть такие, но из них извлечь реальную пользу, ничего не порушив, куда сложнее.
Хорошо в них то, что оба имеют дело уже с «боевым» объектом, причем если AfterConstruction возбуждает исключение, то сначала вызовется BeforeDestruction, а уж потом деструктор.

farcaller Oct 22 2009 at 00:38

Почему-то у меня такое ощущение, что исключения принято вызывать, а возбуждают кой-чего другое. Но, если честно, Object Pascal использовал так давно, что не помню какой там для этого кейворд.

naum Oct 22 2009 at 00:53

raise ;)

farcaller Oct 22 2009 at 00:54

значит русский аналог подобран таки удачно :)

Bonart Oct 22 2009 at 13:35

Учитывая что язык давно уже называется Delphi — неудивительно :)
А «вызов» — слово не слишком удачное, так как после возбуждения исключения в Delphi никакого возврата (как при «нормальных» вызовах) не происходит по определению.

Gorthauer87 Oct 22 2009 at 02:03

Зря на C++ бочку катите, посмотрите, как управление памятью в Qt реализовано

Bonart Oct 22 2009 at 13:32

Никто не отрицает, что на С++ можно и нужно сделать (и неоднократно сделано!) хорошую реализацию управления памятью. Но речь шла о якобы очевидном поведении объектов C++ при создании и уничтожении. Ничего очевидного там, естественно, нет. Жесткий порядок вызова при инициализации, смертельная опасность выброса исключения из конструктора, перезапись указателя VMT, фактическая невиртуальность вызовов оттуда же…

ivlis Oct 22 2009 at 20:18

Всё одна глава в книжке и всё это будете знать. После этого всё кажется очевидно :)

Bonart Oct 23 2009 at 09:32

Я это знаю давно. Но очевидным (т.е. однозначно понятным без точных знаний) оно от давности не стало.

ivlis Oct 23 2009 at 11:40

Однозначно понятным без точных знаний не является ничего.

Paul Oct 23 2009 at 17:11

смертельная опасность выброса исключения из конструктора

W-w-what?

Bonart Oct 23 2009 at 21:19

Формулировка и впрямь слишком резкая. Точнее, бросать исключения из конструктора в C++ требует гораздо больше труда и внимательности, так как деструктор при этом вызван не будет, а неинициализированные части объекта содержат мусор. В результате за очистку при прерывании инициализации отвечает конструктор, не имея вдобавок простых средств для отделения зерна от плевел.
Со стороны C++-программиста на проблему можно посмотреть по ссылке: alenacpp.blogspot.com/2006/11/blog-post.html

Paul Oct 24 2009 at 00:41

Деструкторы будут вызваны для всех полностью сконструированных членов класса и предков. Собственно главное — не бросать исключение в момент, когда какой-то объект находится в «промежуточном» состоянии. Для этого придумано RAII.

Bonart Oct 24 2009 at 12:16

А для не полностью сконструированных конструктор должен все сделать сам. RAII помогает, конечно, но тем не менее дельфийский подход требует намного меньше труда и внимания — достаточно лишь аккуратно написать деструктор.

vpbar Oct 22 2009 at 10:28

Соответственно, в деструкторе достаточно корректно обрабатывать нулевые значения, в чем сильно помогает процедура FreeAndNil, которая освобождает объект, только если ссылка на него уже не nil.

Точнее есть метод Free, который вызывает деструктор если Free был вызван для не нулевого объекта.
А процедура FreeAndNil еще дополнительно обнуляет объект который ей передали.

Bonart Oct 22 2009 at 13:39

Да, имеет смысл упомянуть, что FreeAndNil еще и висячей ссылки за собой не оставляет.
Free не поминал специально, так как считаю его применение в деструкторах (и вообще везде, кроме тех мест где FreeAndNil задействовать невозможно) неправильным.
Почему — успешно объяснено до меня и без меня по ссылке: gunsmoker.blogspot.com/2009/04/freeandnil-free.html

AndrewTishkin Oct 31 2009 at 05:38

Про эту ссылочку:

Ее уже здесь обсуждали, выяснили, что неполезная

delphimaster.ru/cgi-bin/forum.pl?id=1256236718&n=3

Если интересно, могу и предыдущее обсуждение найти, конкретно про обсуждение данной ссылки

Bonart Nov 13 2009 at 09:56

Прочитал.
Участники дискуссии упускают из вида один важный момент (подробно освещенный по ссылке) — двойное удаление есть лишь частный случай использования висячей ссылки на объект, причем самый безобидный. Зато если после удаления будут вызваны любые другие методы объекта, то в случае использования FreeAndNil будет сразу возбуждено исключение, а Free эту ошибку замаскирует, причем наглухо — падать будет не всегда и совсем не там, где ошибка. Это куда более дорогая цена по сравнению с успешным двойным удалением (которое по факту все равно будет успешным однократным).

silentroach Oct 22 2009 at 18:37

Почему-то мне кажется что топик несет в себе ноль полезной информации :(
В чем смысл-то? Перечисление «особенностей», о которых все знают?

Error_403_Forbidden Oct 22 2009 at 18:49

Как ты узнал, что все знают? Я, например, не знал.

silentroach Oct 22 2009 at 19:03

О чем именно из того, что тебе будет полезно, ты не знал? :)

Error_403_Forbidden Oct 22 2009 at 19:21

Доктор, вы задаёте слишком много вопросов.

silentroach Oct 22 2009 at 19:28

Один, самый главный.

SKYnv Oct 22 2009 at 21:06

отучаемся говорить за всех?

silentroach Oct 26 2009 at 11:48

О чем именно из того, что тебе будет полезно, ты не знал? :)

Goodkat Oct 22 2009 at 20:21

возможность создания объектов с неизвестным на этапе компиляции классом

а можно пример?

vpbar Oct 23 2009 at 22:36

см. параграф «Виртуальный конструктор»

Goodkat Oct 24 2009 at 00:12

Пример использования!
Фабрика объектов?

Bonart Oct 24 2009 at 12:23

Пример из RTL Delphi. Этот код создает класс при десериализации его из потока.

  procedure CreateComponent;
  var
    ComponentClass: TComponentClass;
  begin
    try
      ComponentClass := FindComponentClass(CompClass);
      Result := nil;
      if Assigned(FOnCreateComponent) then
        FOnCreateComponent(Self, ComponentClass, Result);
      if Result = nil then
      begin
        Result := TComponent(ComponentClass.NewInstance);
        if ffInline in Flags then
        begin
          Include(Result.FComponentState, csLoading);
          Include(Result.FComponentState, csInline);
        end;
        try
          Result.Create(Owner);
        except
          Result := nil;
          raise;
        end;
      end;
      Include(Result.FComponentState, csLoading);
    except
      if not Recover(Result) then raise;
    end;
  end;

Goodkat Oct 24 2009 at 12:39

Точно!
Спасибо.
Я ещё подумал про сериализацию (a la php), но забыл, что в Delphi тоже используется сериализация (при загрузке форм).

Hint Oct 22 2009 at 22:03

Соответственно, в деструкторе достаточно корректно обрабатывать нулевые значения, в чем сильно помогает процедура FreeAndNil, которая освобождает объект, только если ссылка на него уже не nil.

Delphi 7:

procedure FreeAndNil(var Obj);

var

 Temp: TObject;

begin

 Temp := TObject(Obj);

 Pointer(Obj) := nil;

 Temp.Free;

end;

r13 Oct 22 2009 at 23:02

Об «очевидном» и полезном или создание и уничтожение Delphi
FIXED

UFO just landed and posted this here

aps Oct 23 2009 at 10:47

Delphi, ты еще жив?
В прошлом веке я так любил тебя. Ты был прекрасен.

Bonart Oct 23 2009 at 12:29

Слухи о смерти Delphi оказались несколько преувеличены.
Хотя собственный родитель (Borland) приложил очень много усилий к организации «дельфицида».

aps Oct 23 2009 at 12:57

Одна из самых больших профессиональных ошибок в моей жизни — это то, что в далеком 92-93 году я сориентировался на Borland.
А ведь тогда _нужно_ было предолеть рвотный рефлекс и пересесть на MS. Тогда фаворит был неочевиден а среда Turbo/Delphi давала 100 очков форы MS.
Кто бы знал, что Borland, с его грандиозными планами, уйдет в маргиналии.

Bonart Oct 23 2009 at 14:54

Вряд ли ошибка (если это именно ошибка) была совершена в 92-93 — Delphi вплоть до седьмой версии включительно был более чем на уровне.
Оптимальное время миграции — выход Delphi 8 под .NET. Именно тогда был взят гибельный курс. А вообще лично я не вижу проблемы для программиста с переходом на .NET и сейчас (если, конечно, нет жестких ограничений по времени и заработку прямо сейчас). И не наблюдаю реальных альтернатив Delphi для Win32.

aps Oct 23 2009 at 15:14

>А вообще лично я не вижу проблемы для программиста с переходом на .NET и сейчас
Ключевое слово «сейчас». Тогда в 94 найти работу было крайне сложно. Пришлось преквалифицироваться. Потом еще раз, и еще раз и еще раз… Десктопных приложений с тех пор не писал.
А перескочить с php или perl на .NET достаточно сложно. К тому же длительный перерыв в професии дает о себе знать. Но если бы тогда сориентировался на богомерзкий MS VBasic вместо Delphi (1/2/3) жизнь могла бы пойти по другому. Так мне кажется.

Goodkat Oct 24 2009 at 00:16

Сопссно, C# — это прямой наследник Delphi (или младший брат, учитывая общего родителя :)

aps Oct 24 2009 at 00:36

Меня глючит. Кто общий родитель С# и Delphi???????????????

Вспомнился старый анекдот про лекцию Вирта(Хансена) в испанояычном университете.
Вирта: Вам нравится языка Паскаль?
Студенты: Си, синьор! Си! (sí señor! sí!)

Я вообще-то алгол учил в свое время. И до сих пор скобки расставляю по алгольному.

Goodkat Oct 24 2009 at 12:04

Андерс Хейлсберг
channel9.msdn.com/shows/Behind+The+Code/Life-and-Times-of-Anders-Hejlsberg/

Андерс Хейлсберг получил награду популярного журнала Dr. Dobb's Journal за создание Turbo Pascal, Delphi и C#.

AndrewTishkin Feb 7 2010 at 05:52

Allen Bauer опубликовал в своём блоге заметку по данному поводу:
A case against FreeAndNil

Bonart Feb 14 2010 at 13:55

Все верно, от двойного удаления FreeAndNil не лечит, а маскирует.
Но любое другое использование висячей ссылки после освобождения маскирует уже Free, причем с куда худшими последствиями. Так что если код падает на Free, то сначала надо устранить двойное удаление, а уже потом заменить Free на FreeAndNil — для демаскировки использования висяка.