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

[@megalol]

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

[@Bonart]

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

[@farcaller]

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

[@naum]

raise ;)

[@farcaller]

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

[@Bonart]

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

[@Gorthauer87]

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

[@Bonart]

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

[@ivlis]

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

[@Bonart]

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

[@ivlis]

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

[@Paul]

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

W-w-what?

[@Bonart]

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

[@Paul]

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

[@Bonart]

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

[@vpbar]

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

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

[@Bonart]

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

[@AndrewTishkin]

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

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

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

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

[@Bonart]

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

[@silentroach]

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

[@Error_403_Forbidden]

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

[@silentroach]

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

[@Error_403_Forbidden]

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

[@silentroach]

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

[@SKYnv]

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

[@silentroach]

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

[@Goodkat]

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

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

[@vpbar]

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

[@Goodkat]

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

[@Bonart]

Пример из 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]

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

[@Hint]

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

Delphi 7:

procedure FreeAndNil(var Obj);
var
 Temp: TObject;
begin
 Temp := TObject(Obj);
 Pointer(Obj) := nil;
 Temp.Free;
end;

[@r13]

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

[@aps]

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

[@Bonart]

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

[@aps]

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

[@Bonart]

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

[@aps]

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

[@Goodkat]

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

[@aps]

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

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

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

[@Goodkat]

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

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

[@AndrewTishkin]

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

[@Bonart]

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

[@Severn]

То есть все интерфейсы по-прежнему порождены от IUnknown?
ОК.
Но значит ли это, что любой интерфейс автоматически имеет реализацию, отслеживающую количество ссылок, и освобождающую объект, когда ссылок на него нет?

(Я помню, что такое было у COM-объектов, раньше, году так в 2000...
Но с тех пор я сам перешел на C#, где объявление интерфейса означает только, что у класса есть такие функции, но они могут быть и абстрактными, т.е. без реализации вообще, и уж точно никогда нельзя гарантировать, что вот этот интерфейс будет иметь вот такую реализацию.
Поэтому и спрашиваю у тех, кто может быть в курсе сегодняшнего состояния Паскаля в Дельфах.)