| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
 Добавлено: Ср Сен 01 2004 12:13 Заголовок сообщения: Теория ООП в Delphi |
 |
|
Народ, собственно вопрос специалистам по Delphi по реализации ООП.
Пример, создаем два класса:
| Код: | type Class1 = class(TObject)
private
//Какие-то свойства и объекты класса
//...
public
constructor Create;
destructor Destroy; override;
end;
type Class2 = class(TClass1)
private
FStr : string;
public
constructor Create;
destructor Destroy; override;
end;
...
constructor Class1.Create;
begin
inherited;
//Выделение памяти под объекты Class1
//..
end;
destructor Class1.Destroy;
begin
//Освобождение памяти выделенных для объектов Class1
//...
inherited;
end;
...
constructor Class2.Create;
begin
inherited;
endl
destrucor Class2.Destroy;
begin
inherited;
end; |
Собственно описано два класса. Первый класс содержит какие-то другие объекты, которые создаются в конструкторе класса, и убиваются в деструктору.
Второй является наследником первого, в котором содержится член класса - переменная типа string. Объекты не создаются, память в конструкторе не выделяется и вообще конструктор наследуется у первого класса.
Собственно вопрос.
Такая конструкция имеет место быть:
| Код: | Obj := Class2.Create;
...
Obj.Free; |
А вот такая конструкция имеет право на жизнь?
| Код: | Obj := Class2.Create;
...
Class1(Obj).Free; |
Понятно что ни компилятор ошибок не выдаст, ни во время выполнения ничего фатального не произойдет. Но освободится ли полностью память выделенная для объекта созданного как Class2, но с вызванным методом Class1? С одной стороны вроде как должна, так как метод деструктор класса 2 не делает ничего, а только обращается к деструктору предка. Но может компилятор что-то еще добавляет, ведь в Class2 при создании должна была быть выделена память под строку? Но в конструкторе явно опять же мы ничего не прописывали.
Видимо, это вопрос как устроен менеджер памяти объектов.
Все же мне кажется что такая конструкция должна корректо освобождать память. Хотя я могу и ошибаться.
Надеюсь, кто-нибудь что-нибудь понял и сможет ответить на мой вопрос =) |
|
| Вернуться к началу |
|
 |
Andy-C
Зарегистрирован: 09.12.2003
Сообщения: 73
Откуда: Нальчик
|
| Добавлено: Ср Сен 01 2004 13:50 Заголовок сообщения: А попробовать не бывает :( |
|
|
На сколько я осведомлён в ООП, при вызове виртуального деструктора (на что указывает override?) не вызываются деструкторы предков.
Это не ошибка (компилер не должен ругаться).
_________________
До onlina Andrew C. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Ср Сен 01 2004 14:33 Заголовок сообщения: |
|
|
Вопрос не в этом. А деструктор у нас получился переопределенный, но ведь на то и ключевое слово inherited чтобы вызвать метод предка=)
Впринципе мы можем из Class2 вообще изъять деструктор, для нас ничего это не изменит. Но вот не создаст ли компилятор дельфи невидимо для нас деструктор Class2 для корректного освобождения ресурсов?
Последний раз редактировалось: NetFantom (Ср Сен 01 2004 14:57), всего редактировалось 1 раз |
|
| Вернуться к началу |
|
|
Andy-C
Зарегистрирован: 09.12.2003
Сообщения: 73
Откуда: Нальчик
|
| Добавлено: Ср Сен 01 2004 14:55 Заголовок сообщения: Если маразм не изменяет |
|
|
| NetFantom писал(а): | Вопрос не в этом. А деструктор у нас получился перегруженный =)
Впринципе мы можем из Class2 вообще изъять деструктор, для нас ничего это не изменит. Но вот не создаст ли компилятор дельфи невидимо для нас деструктор Class2 для корректного освобождения ресурсов? |
При наличии явного деструктора, не имеет право создавать.
А вот ежели убить, тогда обязательно создаст.
Другой вопрос о неявном вызове. Тут я не берусь судить...
Хотя, умничать он не должен, да и отследить это проще.
_________________
До onlina Andrew C. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Ср Сен 01 2004 15:01 Заголовок сообщения: |
|
|
Думаешь создаст? А где это написано?
Ну а если явный, может код какой все-равно дописывается, а то ведь в нашем случае мы же не выделяем память для строки. За этим должен видимо проследить конструктор объектов Delphi. Он же и освободит потом это память, другой вопрос не запутаем ли мы его если будем вызывать деструктор предка...Хотя что-то мне кажется что не запутается. Должен он помнить экземпляр какого класса он создал и не привередничать
Я к чему вопрос-то поднял, и в теории интересно, а на практике у меня в приложении утечка памяти, и пока единственное место вызывающее подозрение это. Вот я и хочу разобраться.
Впринципе попробую сейчас CPU-отладчиком проследить, может что накопается. |
|
| Вернуться к началу |
|
|
Andy-C
Зарегистрирован: 09.12.2003
Сообщения: 73
Откуда: Нальчик
|
| Добавлено: Ср Сен 01 2004 15:49 Заголовок сообщения: Заведи лог отведения/освобождения памяти... |
|
|
А как это выявлено?
Ну или лог вызова конструкторов/деструкторов.
В каждом конструкторе/деструкторе писАть допустим в фалик....
На сколько я понимаю, для всех наследников VCL оно грамотно всё подчищает. Вопрос, что может не вовремя (ну, переменная давно не нужна, а живёт до убийства процесса).
Там есть хитрый механизм...
Ну преславутый Parent.
Он при загрузке/записи/удалении должен разруливать своих детишек...
С другой стороны, попускается NULL. 
А расписано у Страуструппа: суть виртуальности деструктора, что не выполняются деструкторы предков (ну, немножко в моей интретрепации).
Найду, процитирую точно....
_________________
До onlina Andrew C. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Ср Сен 01 2004 16:49 Заголовок сообщения: |
|
|
Ну а inherited как раз вызывет метод предка. Это в helpe по Delphi=)
Но ты путаешь. К VCL это не имеент никакого отношения, это же не компонент а объект. Компонент и предки компонентом это уровнем немножко повыше и из другой оперы =) |
|
| Вернуться к началу |
|
|
Andy-C
Зарегистрирован: 09.12.2003
Сообщения: 73
Откуда: Нальчик
|
| Добавлено: Ср Сен 01 2004 17:15 Заголовок сообщения: |
|
|
| NetFantom писал(а): | Ну а inherited как раз вызывет метод предка. Это в helpe по Delphi=)
|
Всё равно выглядит не кашерно.
А смысл насильно вызывать деструктор предка?
По идее, оно сделает приведение типов.
Всё легально.
Вызовет деструктор предка.
Всё легально.
Вернётся.
А вот тут и попа.
Часть унаследованная - на небесах. А новая живая!
Издохнет область видимости.
Оно само вызовет деструктор. Сначала новый. который вызовет унаследованный. Для несуществующего куска. И..... всё рухнет?
Страуструпп говорит вызов освобождения для освобождённого участка, ~ 100% зацикливание в системе отведения памяти.
Может это и устарело.
С другой стороны это динамически выделенный экземпляр и программер несёт ответственность за его освобождение?
Тогда для нового куска деструктор не вызывается, а это есть утечка! 100%
НО! Они говорятт (they say:), что для современных операционок такое безвредно (относительно). Ну, завалит их при невозможности роста свапа
Черевато неосвобождение объектов системы.
Поэтому, я и спрашиваю, как обнаружилась утечка?
| NetFantom писал(а): |
Но ты путаешь. К VCL это не имеент никакого отношения, это же не компонент а объект. Компонент и предки компонентом это уровнем немножко повыше и из другой оперы =) |
Согласен.
Скажем так: объект не наследуемый от чего-либо из VCL, и отношения к нему (вернее к ней, библиотеке) не имеющий
_________________
До onlina Andrew C. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Ср Сен 01 2004 18:57 Заголовок сообщения: |
|
|
Если ты про Inherited то абсолютно кашерно, почитай осоновы ООП для той же дельфи =)
А смысл насильно вызывать...долго объяснять но факт фактом.
Просто есть объект где создается множество различных экземпляров объектов с разными классами, но потомками одного класса, дополненными несколькими новыми полями и статичными функциями.
И хочется вызывать в цикле единый деструктор. Можно конечно проверять объект на принадлежность классу, но не хочется.
Вот такая морковка.
А утечка обнаружилась при отладке - после многократных запусков выделенная память катастрофически увеличилась =))) |
|
| Вернуться к началу |
|
|
wildwind
Зарегистрирован: 03.02.2004
Сообщения: 268
Откуда: Москва
|
| Добавлено: Чт Сен 02 2004 11:53 Заголовок сообщения: |
|
|
Как известно, тип String (который Class2.FStr) в Delphi представляет динамические (размещаемые в куче) строки с подсчетом ссылок. При уничтожении объекта типа Class2 нужно уменьшить количество ссылок на FStr и, если ссылка была последней, освободить память. Вопрос: кто этим должен заниматься? Явно не программист. Я полагаю, что Delphi делает это при вызове Class2.Destroy. Следующий вопрос: делает ли это Delphi при вызове Class1.Destroy (то есть при Class1(Obj).Free)? Я полагаю, что нет, отсюда и утечка памяти.
Вывод: Class1(Obj).Free делать не надо, надо делать Obj.Free.
Вот такая картошка. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Чт Сен 02 2004 12:18 Заголовок сообщения: |
|
|
Да дело даже не в классе String, тут можно было статическую переменную любого типа поставить.
И все-таки хотелось бы на самом деле достоверно узнать что и как...
А проблема еще именно в том что передается как ссылка на объект - Pointer. И вот именно в том и соль была чтобы использовать приведение к классу-предку, так как какой класс был передан заранее неизвестно... |
|
| Вернуться к началу |
|
|
wildwind
Зарегистрирован: 03.02.2004
Сообщения: 268
Откуда: Москва
|
| Добавлено: Чт Сен 02 2004 14:51 Заголовок сообщения: |
|
|
А я думаю, что дело именно в String. Память под поля объекта освобождается в каком-то из методов TObject. Замени String на Integer и продемонстрируй утечку памяти. Тогда посмотрим.
Когда ты приводишь pointer к Class1 и вызываешь Free, а он, в свою очередь, Destroy, то должен вызываться Class2.Destroy, так как Destroy - виртуальный метод. Отследи эти вызовы, как советовал Andy-C. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Чт Сен 02 2004 16:32 Заголовок сообщения: |
|
|
Да нет, тип данных без разницы, лишь бы память статически распределялась.
Но опыт все-таки показал, что Destroy вызывается именно по фактическому типу, а не по формальному. Я тормознул, метод Destroy действиельно виртуальный и перекрывается потомком. Да и теория нашлась:
| Цитата: | | Работа виртуальных методов основана на механизме позднего связывания (late binding). В отличие от раннего связывания (early binding), характерного для статических методов, позднее связывание основано на вычислении адреса вызываемого метода при выполнении программы. Метод вычисляется по хранящемуся в каждом объекте описателю типа. |
А еще покопался в модуле System.
Вообщем, объект унаследованный от базового TObject содержит таблицу описания класса, так что без труда все статические переменные уничтожаются когда вызывается деструктор. |
|
| Вернуться к началу |
|
|
Andy-C
Зарегистрирован: 09.12.2003
Сообщения: 73
Откуда: Нальчик
|
| Добавлено: Пт Сен 03 2004 16:40 Заголовок сообщения: |
|
|
| NetFantom писал(а): | | Да нет, тип данных без разницы, лишь бы память статически распределялась. |
Ну это всё в паскале весьма завуалировано (для меня).
| NetFantom писал(а): |
А еще покопался в модуле System.
Вообщем, объект унаследованный от базового TObject содержит таблицу описания класса, так что без труда все статические переменные уничтожаются когда вызывается деструктор. |
Мы же договорились, что VCL не трогаем
При вызове виртуального деструктора потомка не вызывается деструктор предка.
При вызове деструктора предка не вызывается деструктор потомка.
Вот в чём вопрос
Или утечка, или "двойное освобождение"
Вот это не кашерно 
Если приведённый пример это динамическое распределение памяти, тогда не зависит от типа. 100% утечка.
Если статическое - компилер вызовет сам деструктор при смерти области видимости.
А в дебрях класса оно само может распределять памят (string или ещё что). Её кто будет подчищать?
Для описанного случая (куча маленьких похожих объектов) классики рекомендуют заводить своё управление памятью.
Может стоит поглядеть в сторону STL?
По поводу многократных запусков. Вообще-то при смерти задачи должна освобождаться вся память выделенная этой задачей. Ну, кроме отдельных случаев.
Или я всё путаю?
А что за ОС?
_________________
До onlina Andrew C. |
|
| Вернуться к началу |
|
|
wildwind
Зарегистрирован: 03.02.2004
Сообщения: 268
Откуда: Москва
|
| Добавлено: Пт Сен 03 2004 16:50 Заголовок сообщения: |
|
|
| Да, к сожалению ты все путаешь. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Пт Сен 03 2004 18:49 Заголовок сообщения: |
|
|
Да, путаешь многое =)))
| Цитата: | | Мы же договорились, что VCL не трогаем |
Так и не трогаем =) Модуль System и TObject никакого отношения к VCL не имеет. TObject это просто базовый класс всех объектов в Delphi. Объектов, а не VCL компонентов!
| Цитата: | При вызове виртуального деструктора потомка не вызывается деструктор предка.
При вызове деструктора предка не вызывается деструктор потомка.
Вот в чём вопрос |
Я оглянулся посмотреть не оглянулась ли она =))) Дело не в деструкторах а именно в переопределенных виртуальных функциях.
Если функция Func описана в классе TClass1 как виртуальная, а в классе TClass2 переопределена (override), то при условии что Obj это экземпляр объекта Class2 вызовы
| Код: |
Class2(Obj).Func;
Class1(Obj).Func;
(Obj as Class1).Func;
Obj.Func;
|
Приведут к одному и тому же результату - вызовется функция TClass2.
Поэтом и именно поэтому мы не можем обратиться к деструктору предка извне, если в потомке он переопределен. Мы можем только из деструктора потомка вызвать деструктор предка оператором inherited.
| Цитата: | Если приведённый пример это динамическое распределение памяти, тогда не зависит от типа. 100% утечка.
Если статическое - компилер вызовет сам деструктор при смерти области видимости. |
Я не совсем удачно выразился видимо, использовав термины "статические" и "динамические" переменные. В контексте МОДУЛЯ, ФУНКЦИИ и ПРОГРАММЫ ты абсолютно прав, но в контексте ОБЪЕКТОВ память в любом случае будет выделятся динамически. Я лишь имел ввиду и назвал ДИНАМИЧЕСКИМИ те переменные, для которых мы САМИ выделяем память в конструкторах, например
| Цитата: | private
TSomeObj : TObject;
...
constructor Create;
begin
TSimeObj := TObject.Createl
end; |
и статическими те, для которых выделяет память Delphi (точнее это базовый класс TObject) и о которых мы не задумывается. А сюда входят и ShortString и AnsiString и численные типы данных и прочее.
И он же потом подчищает память (ReleaseInstanse функция например, если память не изменяет она как-раз подчищает память AnsiString переменных).
| Цитата: | По поводу многократных запусков. Вообще-то при смерти задачи должна освобождаться вся память выделенная этой задачей. Ну, кроме отдельных случаев.
Или я всё путаю?
А что за ОС? |
Ну чисто теоретически так должно бы быть, но фактически такое происходит очень редко.
А платформа Windows вестимо =) XP. Хотя и в 2000 все так же будет при потере памяти.
А моя проблемма все-таки в чем-то другом, где-то я память еще теряю..и как бы найти это место =) |
|
| Вернуться к началу |
|
|
Andy-C
Зарегистрирован: 09.12.2003
Сообщения: 73
Откуда: Нальчик
|
| Добавлено: Пт Сен 03 2004 19:38 Заголовок сообщения: |
|
|
| NetFantom писал(а): | | Да, путаешь многое =))) |
Печально.....
| NetFantom писал(а): |
Так и не трогаем =) Модуль System и TObject никакого отношения к VCL не имеет. TObject это просто базовый класс всех объектов в Delphi. Объектов, а не VCL компонентов! |
А вот это обсолютная неправда!
TObject является базовым классом для всей иерархии VCL.
Правда-правда.
Сам только-что проверил
type
my_class = class
public
i: integer;
end;
Делфи кушает!
| NetFantom писал(а): |
Я оглянулся посмотреть не оглянулась ли она =))) Дело не в
Sory skip......
деструктора потомка вызвать деструктор предка оператором inherited.
|
Дело именно в виртуальных деструкторах, т.к. они некоректно манипулируют с памятью..
| NetFantom писал(а): |
..... но в контексте ОБЪЕКТОВ память в любом случае будет выделятся динамически.
|
НЕ ВЕРЮ!!!!!! Всё дело в наследовании от VCL.
| NetFantom писал(а): |
Ну чисто теоретически так должно бы быть, но фактически такое происходит очень редко.
А платформа Windows вестимо =) XP. Хотя и в 2000 все так же будет при потере памяти. |
| NetFantom писал(а): |
А моя проблемма все-таки в чем-то другом, где-то я память еще теряю..и как бы найти это место =) |
ИЩИТЕ ДА ОБРЯЩИТЕ.......
_________________
До onlina Andrew C. |
|
| Вернуться к началу |
|
|
Andy-C
Зарегистрирован: 09.12.2003
Сообщения: 73
Откуда: Нальчик
|
| Добавлено: Пт Сен 03 2004 19:56 Заголовок сообщения: |
|
|
К стати! Програмки на Делфи можно писАть без VCL
см. KOL.
Mirror Classes Kit for Key Objects Library, v1.55 [19-Oct-2002]
Copyright (C) 1999, 2000-2002 by Vladimir Kladov
Кажись:
http://xcl.cjb.net
bonanzas@xcl.cjb.net
Весьма занятная штука!
Можешь сделать эксперимент хранить ссылки на объекты которые уже удалены вызовом деструктора предка. А потом обратиться к какому-нть контрольному полю. Только после интенчивной работы с памятью.
Если AV, с обльшой вероятностью память освобождена.
Если всё хорошо, тады ой, таки утечка!
Должны быть пакеты для контроля манипуляций с памятью.
_________________
До onlina Andrew C. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Сб Сен 04 2004 17:10 Заголовок сообщения: |
|
|
| Цитата: | А вот это обсолютная неправда!
TObject является базовым классом для всей иерархии VCL.
Правда-правда.
Сам только-что проверил |
Уфф...ну конечно, так как VCL объектно-ориентированно то основано на TObject, как и все объекты, что я и писал.
Но это же не значит что TObject и ООП это VCL - правильнее сказать что VCL основан на TObject. Это и только это я и имел ввиду, когда писал что VCL тут непричем. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Сб Сен 04 2004 17:12 Заголовок сообщения: |
|
|
| Да нет, все объекты нормально удаляются, это уже доказано, см. выше =) |
|
| Вернуться к началу |
|
|
Go
Гость
|
| Добавлено: Пн Сен 06 2004 07:21 Заголовок сообщения: п |
|
|
а большая утечка то?
может она временная
(кеш-менеджер тормозит)? |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Пн Сен 06 2004 17:31 Заголовок сообщения: |
|
|
Утечка приличная, правда подсчитывать точно пока лень =)
На несколько метров при каждом запуске. Понятное дело что при отладке у меня со временем выделенной памяти начинает шкалить за 700мегабайт. |
|
| Вернуться к началу |
|
|
Andy-C
Зарегистрирован: 09.12.2003
Сообщения: 73
Откуда: Нальчик
|
| Добавлено: Вт Сен 07 2004 07:22 Заголовок сообщения: |
|
|
Предлагаю эксперимент:
Откажись от виртуальных деструкторов.
Вызывай их в нужном порядке.
Если утечки не будет, значит оно?
_________________
До onlina Andrew C. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Вт Сен 07 2004 14:14 Заголовок сообщения: |
|
|
Мил человек, как же я откажусь-то если я наследуюсь от TObject в котором дуструктор объявлен как
destructor Destroy; virtual;
Да и разобрались уже что тут утечки вроде как нету... |
|
| Вернуться к началу |
|
|
Andy-C
Зарегистрирован: 09.12.2003
Сообщения: 73
Откуда: Нальчик
|
| Добавлено: Вт Сен 07 2004 15:32 Заголовок сообщения: |
|
|
Disposes of an object instance.
Delphi syntax:
destructor Destroy; virtual;
Description
Do not call Destroy directly. Call Free instead. Free verifies that the object reference is not nil before calling Destroy.
И соответственно:
Destroys an object and frees its associated memory, if necessary.
Delphi syntax:
procedure Free;
C++ syntax:
__fastcall Free();
И т.п.
Даже бооманланд рекомендует не вызывать виртеальный деструктор напрямую
Может чего прояснит: http://www.rsdn.ru/article/Delphi/memmanager.xml
_________________
До onlina Andrew C. |
|
| Вернуться к началу |
|
|
NetFantom
Зарегистрирован: 27.01.2004
Сообщения: 41
Откуда: Санкт-Петербург
|
| Добавлено: Вт Сен 07 2004 17:41 Заголовок сообщения: |
|
|
Да блин, это те же яйца только в профиль. Прочитай ВНИМАТЕЛЬНО что написано про метод Free или посмотри его код. он просто проверяет равенство указателя NIL и вызывает тот же деструктор. С памятью он ничего не делает.
Но если на то пошло то у меня в коде именно FREE метод вызывается. хотя в данном случае абсолютно параллельно что Free что Destroy - так или иначе деструктор вызовется.
А ссылочку сейчас посмотрю. Пасиб. |
|
| Вернуться к началу |
|
|
|
FAQ 
Поиск 
Пользователи 
Группы
Регистрация
Профиль 
Войти и проверить личные сообщения 
Вход 
