Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата Shaggy @ 11.02.13, 15:01

хм...

? а... это, Destroy - это деструктор в Делфи, да? И в Делфи можно в теле деструктора указывать путем inherited; порядок вызова родительского? Ппц
Спасибо кнечно, и ничего против не имею, но мне б и так не подошло - т.к. дочерний класс я писал не на Делфи.

Добавлено 11.02.13, 15:11
Shaggy, все равно не понял. Зачем мне после inherited; удалять свое, если сам факт вызова inherited вызовет родительский деструктор в котором вызовется Clear в котором свое уже и так потрется?

Цитата Shaggy @ 11.02.13, 15:01

Цитата Chow @ 11.02.13, 14:41

"хорошо" что это был VCL-ный класс у которого есть ComponentState

хм...

destructor TMyObj.Destroy;
begin
  inherited;
  // удаляем своё
end;

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

Мляаааааа... Как это всё мило

А слабо чистить так, чтобы даже повторный вызов работал правильно? Тогда и флаги не нужны

Цитата Chow @ 11.02.13, 15:07

Зачем мне после inherited; удалять свое, если сам факт вызова inherited вызовет родительский деструктор в котором вызовется Clear в котором свое уже и так потрется?

1. на примере:
твоё поле - список
тогда в clear - list.clear
в деструкторе - list.free;

2. если же ты в clear именно удаляешь поле, то это надо делать так:
anyobj.free;
anyobj:=nil
или
freeandnil(anyobj);

а иначе(если ты не заnilивашь ссылку) ССЗБ, тебе не кажется?

D_KEY, как бы фабрика выглядела на сях?

Цитата --Ins-- @ 11.02.13, 15:23

А слабо чистить так, чтобы даже повторный вызов работал правильно?

кстати, да
два clear подряд и av - замечательно

Цитата --Ins-- @ 11.02.13, 15:26

D_KEY, как бы фабрика выглядела на сях?

На сях? Тяжко.
На С++ правда тоже не слишком красиво - нужно ручками регистрировать нужные типы, если хотим получать объекты по имени класса, например.

Добавлено 11.02.13, 15:34

Цитата Shaggy @ 11.02.13, 15:23

ССЗБ, тебе не кажется?

Ну так сначала создали проблему в языке, а вы теперь ее героически преодолеваете.

Цитата D_KEY @ 11.02.13, 15:30

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

это уже просто упрямство
решение т.н. "проблемы" не займёт и строчки кода
поле всё равно удаляем, так напиши freeandnil(obj) вместо obj.free
и всё, с деструктором шаманить не придётся

Цитата Shaggy @ 11.02.13, 15:43

поле всё равно удаляем

Зачем это делать руками ? Неудобно ведь и забыть можно...

Цитата --Ins-- @ 11.02.13, 11:01

А на самом деле там очень гибкий процесс конструирования с возможностью программиста вмешиваться в различные этапы и элегантно реализовывать многие сложные вещи

А зачем вмешиваться во что-то кем-то написанное на разных этапах, если в результате всё получим кастомное? Не проще ли в этом случае кастомно сразу и написать? Эффективнее будет работать, и платить не придётся, если не юзаем.

Цитата D_KEY @ 11.02.13, 15:46

Зачем это делать руками ? Неудобно ведь и забыть можно...

мы всё ещё про пример Chow, да?

метод clear(не деструктор), удаление поля
как это можно сделать "не руками"?

Цитата D_KEY @ 11.02.13, 15:30

На С++ правда тоже не слишком красиво - нужно ручками регистрировать нужные типы, если хотим получать объекты по имени класса, например.

А ты говоришь, зачем нужно, зачем нужно... Чтобы не было тяжко, вестимо. Человеческий мозг и время - слишком ценный ресурс, чтобы тратить его на то, что можно автоматизировать

Цитата D_KEY @ 11.02.13, 15:17

В любом случае - каша и никакого разделения между классами иерархии

Это лютый бред, и он не выдерживает никакой критики. Точно так же можно заявить, что виртуальные методы в принципе создают кашу и отсутствие разделения между классами в иерархии. Ведь возможна гипотетическая ситуация, что ты перекрываешь виртуальный метод так, что он, будучи использованным в базовом классе который писал не ты, приведет к чему-то неожиданному и непредвиденному. Кто тебя знает, как тебе вздумается его перекрыть? И ты ведь не обязан знять реализацию базового класса. Вывод - надо запретить вызов виртуальных методов в базовом классе
Еще раз: это полная хня. Единственная причина, почему в с++, Java, шарпе и т.д. пишут что не нужно вызывать вирт. методы в конструкторах - потому что там ты в случае чего не сможешь эту ситуацию разрулить. А в Delphi - сможешь, поэтому все сишные аргументы тут неприменимы

Сообщение отредактировано: --Ins-- - 11.02.13, 15:58

Цитата Shaggy @ 11.02.13, 15:43

поле всё равно удаляем, так напиши freeandnil(obj) вместо obj.free

Многие Дельфисты даже помешались на этом FreeAndNil настолько, что используют даже для _локальных_ объектов, вроде:

var
  MyObj: TMyClass;
begin
  MyObj := TMyClass.Create;
  try
    // do something with MyObj
  finally
    FreeAndNil(MyObj);
  end
end;

Спрашиваешь: зачем? Отвечают: мол, чтобы привыкнуть и в случае реальной необходимости не забыть

Добавлено 11.02.13, 15:59

Цитата --Ins-- @ 11.02.13, 15:56

Еще раз: это полная хня. Единственная причина, почему в с++, Java, шарпе и т.д. пишут что не нужно вызывать вирт. методы в конструкторах - потому что там ты в случае чего не сможешь эту ситуацию разрулить. А в Delphi - сможешь, поэтому все сишные аргументы тут неприменимы

Работал я когда-то над проектом, ядро для которого разрабатывал другой программист. Проект использовал табулированный интерфейс и ОЧЕНЬ часто вылетал при закрытии вкладок. А все из-за того что освобождение содержимого вкладки делалось в... BeforeDestruction! Вот посмотришь на такие примеры, и понимаешь, что не дураки все-таки Джаву разрабатывали Там таких проблем не может быть априори.

Цитата [S]mike @ 11.02.13, 15:56

Работал я когда-то над проектом, ядро для которого разрабатывал другой программист. Проект использовал табулированный интерфейс и ОЧЕНЬ часто вылетал при закрытии вкладок. А все из-за того что освобождение содержимого вкладки делалось в... BeforeDestruction!

Ну дурак разработчик, Delphi то причем? Чьи-то кривые руки не делают инструмент, которые они держат, кривым. Я тебе могу привести примеры элегантного использования того же BeforeDestruction

Сообщение отредактировано: --Ins-- - 11.02.13, 16:01