Free()

← →
evvcom © (2007-02-20 12:11) [40]

> [38] Loginov Dmitry © (20.02.07 12:00)
> Все так.

Хозяин - барин. Тогда зачем ты здесь?

← →
Loginov Dmitry © (2007-02-20 12:11) [41]

> Похоже, сомнения, мучавшие при написании subj-а, совсем
> прошли :)

Да совсем прошли. Если 2/3 постов проигнорить, то получится, что все "благословили" мою задумку :))

← →
ЮЮ © (2007-02-20 12:23) [42]

Если 2/3 постов проигнорить,
то останется 1/3 твоих постов. Ибо ни в одном, кроме твоих, благословения не наблюдал :)

← →
Аноним (2007-02-20 12:53) [43]

> Использовать такой глобальный список я не хочу по 3-м причинам:
>
> 1 - не хочу иметь проблем при использовании многопоточности
> 2 - при создании большого числа объектов работа со списком
> начнет тормозить
> 3 - при компиляции модуля без пакетов в EXE и в DLL списки
> будут у каждого свои, и функция будет работать неверно.

1. Обходится тремя доп строками кода.
2. Не будет тормозить. Если их и правда миллион - сортировать список по абс. значению указателя - летать будет со свистом
а если не миллион а тысяца - то и без сортировки не заметишь тормозов - операция очень быстрая
3. Ты что - собираешься эти матрицы между exe и Dll передавать в виде указателей и без bwrtp ?
Если так, то удачи желать бесполезно, ее не будет

← →
reonid © (2007-02-20 12:58) [44]

2Loginov Dmitry © (20.02.07 12:11)

Мне кажется, будет милосерднее по отношению к пользователям
твоей библиотеки дать им разбираться со своими ошибками, чем с твоими.
Лекарство может оказаться хуже болезни. ИМХО...

← →
icWasya © (2007-02-20 12:59) [45]

А не лучше сделать так ?
procedure FreeAndNil(var M:TMatrix);overload; var MM:TMatrix; begin MM:=M; M:=Nil; if MM = nil then Exit; if MatrixRefIsValid(MM) then Destroy; end;

← →
Lamer@fools.ua © (2007-02-20 13:07) [46]

После [19], пожалуй, соглашусь с [13].

← →
Loginov Dmitry © (2007-02-20 15:08) [47]

> [43] Аноним (20.02.07 12:53)
>
> 1. Обходится тремя доп строками кода.
> 2. Не будет тормозить. Если их и правда миллион - сортировать
> список по абс. значению указателя - летать будет со свистом
> а если не миллион а тысяца - то и без сортировки не заметишь
> тормозов - операция очень быстрая

Для чего писать якобы 3 строки кода, если существующий механизм итак отлично работает? Он надежный, быстрый, с ним никаких проблем. Что такого особенного даст то, что я буду использовать глобальный список? Надежность? Нет (надежнее программа не станет)! Скорость? Врядли (если только тормоза внесет)! Только дополнительную работу и описанную проблему с DLL.

> 3. Ты что - собираешься эти матрицы между exe и Dll передавать
> в виде указателей и без bwrtp ?

А что тут такого? Подключил ShareMem (FastMM и т.п.) - и вперед. Главное, чтобы программа не глючила. А глобальный список будет таким стремлениям только мешать.

Кстати дай расшифровку буквосочетанию bwrtp...

> [44] reonid © (20.02.07 12:58)
>
> Мне кажется, будет милосерднее по отношению к пользователям
> твоей библиотеки дать им разбираться со своими ошибками, чем с твоими.

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

Как вы думаете, сколько времени должно уйти на поиск ошибки, подобной этой:

procedure TForm1.Button1Click(Sender: TObject); var AList: TList; begin AList := TList.Create; AList.Free; AList.Free; end;

В 70% случаев повторный вызов AList.Free; никакого AV не выдает - все просто замечательно. Однако AV начинают появляться при работе программы в дальнейшем. Пользователь работает, работает - и бац - AV. Причем адрес в тексте ошибок может быть любым. С другой стороны после повторного вызова Free ошибка может и не возникнут. И так от запуска к запуску - то AV, то все нормально. Вот дела-то!
Потом: AV после повторного вызова Free() не всегда бывает шуточным. Эта ошибка может запросто парализовать дальнейшую работу всего приложения. Выловить такую ошибку - достаточно трудно (я-то привел простейший случай, когда 2 Free идут подряд друг за другом, в жизни обычно не так). Такие ошибки профессионалы не допускают. Новичек - запросто! Профессионал если даже и допустит подобную ошибку - в его арсенале куча отладочных средств и других возможностей. У новичка - напротив. С одной ошибкой может е...ться сутками.

Я же в рамках своего класса предлагаю очень простой выход из подобных крайне редких ситуаций. Меня же за это пинают все кто на что горазд. Однако никто так и не сумел однозначно сказать, почему это х..ня. Ссылаются на VCL, Notifycation, и бог знает на что еще. Некоторые даже начали учить искуству дворника (вероятно ищут себе замену).

> [46] Lamer@fools.ua © (20.02.07 13:07)
> После [19], пожалуй, соглашусь с [13].

Тоже ищете себе замену?

← →
Сергей М. © (2007-02-20 15:30) [48]

> Loginov Dmitry © (20.02.07 15:08) [47]

> Как вы думаете, сколько времени должно уйти на поиск ошибки,
> подобной этой

Сколько бы ни ушло, это не твоя ошибка, а ошибка разработчика, использующено твой класс.

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

← →
Аноним (2007-02-20 16:58) [49]

> Loginov Dmitry ©

> А что тут такого? Подключил ShareMem (FastMM и т.п.) - и
> вперед.

то есть программисту надо будет еще и как минимум помнить, что нельзя использовать IS (AS), а как максимум - что нужно обязательно собирать хост и библиотеку с одинаковыми настройками выравнивания, и так далее?
а также забыть о языковой независимости, и о варианте "хост и библиотека собраны разными версиями D"
Это уже намного серьезнее, чем внесение путаницы в Free.

Я просто так делал, давно еще. И получил в результате те самые

> Однако AV начинают появляться при работе программы в дальнейшем.
> Пользователь работает, работает - и бац - AV

ПРи повышении беспорядка в системе наступает момент, когда количество переходит в качество. То есть количество бардака приводит к тому что все перестает работать вообще, это называется "проваленный проект"

> Кстати дай расшифровку буквосочетанию bwrtp...

Build with run time packages

← →
Суслик © (2007-02-20 17:16) [50]

вот упрямый то :)
спорить с тобой бессмыслено.

очень советую распространять свою библиотеку в ТОЛЬКО в бинарниках - чтобы никто кода не видел ибо ни один программист пользовать библиотеку с таким кодом не будет ибо это вызывает сомнения в образовании автора библиотеки.

ЗЫ
вот эта функция function MatrixRefIsValid(AMatrix: TMatrix): Boolean еще вроде ничего - похожа на работоспособную ибо обращение к AMatrix.FLifeGUID ни к чему, кроме AV привести не может, т.к. FLifeGUID есть поле, а не метод.
т.е. не будет ни privileged instruction, ни порчи чужой памяти.

← →
Ketmar © (2007-02-20 17:37) [51]

из очереди на метлу вычёркиваю. или сломает, или потеряет.

← →
oldman © (2007-02-20 17:43) [52]

> Теперь сомнения мучают, нет ли тут каких-нибудь неучтенных
> граблей?

Пользуй стандартный и пересмотри свой код на тему удаления несуществующего...
Подразумевается (имхо), что при правильном коде все стандартное должно работать :)

← →
Loginov Dmitry © (2007-02-20 17:54) [53]

> очень советую распространять свою библиотеку в ТОЛЬКО в
> бинарниках - чтобы никто кода не видел ибо ни один программист
> пользовать библиотеку с таким кодом не будет ибо это вызывает
> сомнения в образовании автора библиотеки.

Сказать честно - зря вы так! Библиотека большая, спорного кода очень немного. Весь этот спорный код я привел здесь. Реакцию на этот код почувствовал на себе. Всю критику я учел и сделаю соответствующие изменения в библиотеке.

> вот эта функция function MatrixRefIsValid(AMatrix: TMatrix)
> : Boolean еще вроде ничего - похожа на работоспособную ибо
> обращение к AMatrix.FLifeGUID ни к чему, кроме AV привести
> не может

Безболезненный AV - наиболее "опасная" ситуация при обращении к полю FLifeGUID.
Даже этого AV практически никогда не возникает.

← →
Суслик © (2007-02-20 17:59) [54]

> [53] Loginov Dmitry © (20.02.07 17:54)

Я тебе так скажу, что есть определенные правила языка, которые лушче все же соблюдать.
Сам понимаешь, что в борланде не дураки сидят. Как раз для таких как ты, которые хотят помочь юзеру твоей библиотеки, у них есть замечательная штука fastmm. Пьер Ле Риш (автор ее) уж не знаю на каких основаниях дал ее использовать в дельфи, но результат один - библиотека офигительно помогает в отладке.

В любом языке есть некоторые precondition, а precondition на то они и precondition, что их фиг проверишь - "живость" объекта есть ответственность вызывающей стороны. Если вызывающая сторона испытывает сложности с отладкой - на это есть тот самый fastmm.

← →
Суслик © (2007-02-20 18:04) [55]

Еще.

уж поверь, что информативность fastmm много выше, чем информативность предоставляемая твоим способом.

нужно просто скачать fastmm (полную версию, хотя она и bds2006 есть), прочесть inc файл, поставить первым модулем - и получать очень информативный стек вызовов, который привел к ошибке.

ты пойми, что обеспечить информативность твоим способом просто невозможно, если твоя матрица лежит в TObjectList. Если список удаляется он пытается удалить твою матрицу. Т.е. факт вызова деструктора тобой не контролируется. Тут ты уже ничего сделать не сможешь, если ссылка битая.

тот же fastmm тебе выведет подробный стек, где и когда был объект удален в предыдущий раз.

← →
Loginov Dmitry © (2007-02-20 18:07) [56]

Я сейчас в большинстве проектов юзаю FastMM4. Вы правы - штука действительно офигительная. Забудешь один байт освободить, так и будет докапываться, пока все не исправишь :)

← →
Суслик © (2007-02-20 18:13) [57]

Я очень рад за тебя, что ты это дело юзаешь.
Прьер переодически правит ее, и библиотека становится все более полезной.
Ты все равно ее не переплюнешь в части помощи пользователю, да и зачем это надо? Он очень граммотный программист, я с ним переодически переписываюсь - его уровень знания RTL много выше чем наш с тобой. Ты лучше ошибку в ней найди какую-нибудь :) В основном все правки - это именно баги, найденные в части сервисных функций данного манагера памяти.

Лучше рассчитывать на то, что твой пользователь не новичок, раз пользуется такой библиотекой как твоя :) (шутка, ну ты понял).

← →
Lamer@fools.ua © (2007-02-20 18:24) [58]

>>Loginov Dmitry © (20.02.07 15:08) [47]

>Тоже ищете себе замену?
Не-е. Дело в том, что кроме меня ещё один ламер нужен. Только покруче.

← →
Loginov Dmitry © (2007-02-20 18:32) [59]

> ты пойми, что обеспечить информативность твоим способом
> просто невозможно, если твоя матрица лежит в TObjectList.
> Если список удаляется он пытается удалить твою матрицу.
> Т.е. факт вызова деструктора тобой не контролируется. Тут
> ты уже ничего сделать не сможешь, если ссылка битая.

Я давным-давно знаю про это и вполне четко понимаю. У меня проверка Self стоит и в деструкторе, так что, грубо говоря, в 50% случаев программа на эту проверку напорется даже при попытке уничтожения объекта с помощью "битой" ссилки, хранимой в TObjectList. Это не панацея. Для большего у меня возможностей нет.

> Ты все равно ее не переплюнешь в части помощи пользователю,
> да и зачем это надо? Он очень граммотный программист, я
> с ним переодически переписываюсь - его уровень знания RTL
> много выше чем наш с тобой. Ты лучше ошибку в ней найди
> какую-нибудь :) В основном все правки - это именно баги,
> найденные в части сервисных функций данного манагера памяти.

Я час читал это историю по исправлению баг (так и не дочитал). Наверное целая армия участвовала в этом процессе. Так что я согласен что это самый мощный манагер памяти :)

> Лучше рассчитывать на то, что твой пользователь не новичок,
> раз пользуется такой библиотекой как твоя :) (шутка, ну
> ты понял).

В глубине души я все-еще надеюсь, что пользоваться ею будут те, кому эта библиотека окажется полезной (как новички, так и профи). Стараюсь сделать ее надежной (чтобы надежность ни у кого не вызывала сомнений), и чтобы в ней нельзя было ни к чему придраться. Это очень сложная и ответственная задача (сколько библиотек кроме FastMM выполняют такие требования?)

← →
Суслик © (2007-02-20 18:41) [60]

> Я давным-давно знаю про это и вполне четко понимаю. У меня
> проверка Self стоит и в деструкторе, так что, грубо говоря,
> в 50% случаев программа на эту проверку напорется даже при
> попытке уничтожения объекта с помощью "битой" ссилки, хранимой
> в TObjectList. Это не панацея. Для большего у меня возможностей
> нет.

Э... как бы тебе сказать - ты здесь в корне не прав :)
деструктор метод виртуальный. Верно? К чему межет привести вызов виртуального метода у битой ссылки? Ладно уж к AV, намного хуже, что может вызываться вообще черт значет что. Со всеми вытекающими - порча чужих данных и все такое. После этого программа может потерять работоспособность как таковая.

> Я час читал это историю по исправлению баг (так и не дочитал).
> Наверное целая армия участвовала в этом процессе. Так что
> я согласен что это самый мощный манагер памяти :)

Нет, он один. Он единственный автор. А вот баги и идеи пишут многие. Из России в том числе несколько человек. Я тоже какой-то баг там находил - он в *некоторых случаях* неверно определял тип утекаемых данных если это была строка. Ты тоже можешь принять участие.

> Это очень сложная и ответственная задача (сколько библиотек
> кроме FastMM выполняют такие требования?)

Ты не путай ж. с пальцем. Ты просто таки должен понимать, что в языке типа Дельфи ты не сможешь обеспечить прямоту рук используеющего твою библиотеку (я надеюсь, ты это понимаешь?). Это язык с прямым доступом к памяти, со всеми вытекающими.
ФастММ существует для исправления рук. Твоя же задача написать библиотеку, которая делает то, для чего она вообще была создана - матричные вычисления.

← →
Ketmar © (2007-02-20 18:44) [61]

хм. мрамрные шарики тоже не доверять.

← →
Суслик © (2007-02-20 18:45) [62]

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

Ерунда какая-то. Т.е. ты делаешь лишнюю работу.

← →
Loginov Dmitry © (2007-02-20 18:46) [63]

> Э... как бы тебе сказать - ты здесь в корне не прав :)
> деструктор метод виртуальный. Верно? К чему межет привести
> вызов виртуального метода у битой ссылки? Ладно уж к AV,
> намного хуже, что может вызываться вообще черт значет что.
> Со всеми вытекающими - порча чужих данных и все такое. После
> этого программа может потерять работоспособность как таковая.

Вы повторили то, что я описывал в [47] насчет AList.Free.

← →
Суслик © (2007-02-20 18:49) [64]

А ты почитай [62] - там тоже мысль здравая.
Желаю успехов.

← →
Суслик © (2007-02-20 18:51) [65]

2автор
в борландовом QC открыты репорты по перегрузке _initializeRecord и _finalizeRecord. Если они это сделают, то ты с полным правом можешь реализовывать на основе этого некое подобие сборщика мусора. Пока же - это мертвому припарки - если чесловек (твой пользователь) не соблюдает precondition, то ему не нужно писать на языке, на котором он пишет.

← →
Ketmar © (2007-02-20 19:35) [66]

> Суслик © (20.02.07 18:51) [65]
оставь надежду... раньше Дима был адекватный. а теперь стал "нормальным".

← →
Суслик © (2007-02-20 19:43) [67]

> [66] Ketmar © (20.02.07 19:35)

Я тут неожиданно почуял высшую миссию нести истину людям :)

← →
Loginov Dmitry © (2007-02-20 19:55) [68]

На компромисс я всеж-таки пошел:

добавил опцию условной компиляции UseExtendedFree для компиляции собственного метода Free()
добавил опцию условной компиляции UseLifeGuid. Если она отключена, то используется (в потокобезопасном режиме) список созданных объектов TList.

И чем не компромисс?

> Я тут неожиданно почуял высшую миссию нести истину людям :)

Там это все вспомнят и воздадут по заслугам, и вознесут... :))

← →
Аноним (2007-02-21 09:41) [70]

> Loginov Dmitry ©

> добавил опцию условной компиляции

Ну и зря :-)
ИМХО, чем меньше дефайнов, тем лучше. Я лично ввожу их только в том случае, когда без них совсем никак. А ты на ровном месте аж две штуки породил. Если так пойдет дальше, в них потом сам черт ногу сломит.

> Ну и зря :-)
> ИМХО, чем меньше дефайнов, тем лучше. Я лично ввожу их только
> в том случае, когда без них совсем никак. А ты на ровном
> месте аж две штуки породил. Если так пойдет дальше, в них
> потом сам черт ногу сломит.

сильно от задачи зависит.
самый жуткий модуль, который я видел это fastmm4.pas - безумное кол-во дефайнов.

> ИМХО, чем меньше дефайнов, тем лучше. Я лично ввожу их только
> в том случае, когда без них совсем никак. А ты на ровном
> месте аж две штуки породил. Если так пойдет дальше, в них
> потом сам черт ногу сломит.

А не сломит. Там комментарии есть. На русском :))

Ветка оказалась очень продуктивной. Не ожидал даже. Учтя все изложенные выше нарекания, критику, советы, хорошенько перекроил модуль.

http://matrix.kladovka.net.ru/download.php?getfilename=uploads/heart/matrix32.zip

Надеюсь, теперь сомнений в надежности модуля ни у кого не будет. Очень надеюсь :)

procedure RaiseException(const AText: string); begin raise Exception.Create(AText); end; function TMatrix.DimCols: Integer; begin if DimensionCount > 0 then Result := DimensionCount - 1 else begin RaiseException(matSDimensionError); Result := -1; end; end;
Дмитрий, если честно, то мое личное ИМХО такое - я считаю, что выделенная строка свидетельствует, что квалификация программиста недостаточна для того, чтобы его коду можно было доверять даже на 90%. А без 99%-ной уверенности я чужой код не использую.

Наверное, нужны пояснения. Вот стиль, увидев который я бы решил, что квалификация автора вполне достаточна для разработки библиотек общего назначения и поэтому его код заслуживает дальнейшего рассмотрения.
type EMatrixError = class(EMathError); procedure RaiseMatrixError(const AText: string); begin raise EMatrixError.Create(AText) end; function TMatrix.DimCols: Integer; begin if DimensionCount <= 0 then RaiseMatrixError(matSDimensionError); Result := DimensionCount - 1 end;
Вроде бы, то же самое? То же, да не совсем.

Во-первых, свой класс исключения (причем c правильным по смыслу наследованием) позволяет мне, как пользователю библиотеки, строить в моей программе гибкую обработку ошибок - и сам факт того, что автор об этом позаботился, уже говорит о том, что уровень его мышления перерос рамки прикладного программирования (for end-user) и созрел до уровня, необходимого для разработки инструментария. То есть, о достаточном опыте и квалификации.

Во-вторых, код полон и одновременно компактен (то есть, в нем есть все, что нужно и нет ни одной лишней буквы). ИМХО, такой четкий стиль тоже свидетельствует о том, что коду верить можно.

2[75]
Со всем согласен, кроме пользы от наследования от EMathError.
Расскажи, если не сложно, пример практической пользы наследования от EMathError.

PS. Я лично всегда объявляю предка для исключения, который свойственнен текущей библиотеке или классу

Например

type TMatrix = class public type EException = class abstract(Exception); public type EWrongCoord = class sealed(EException); public procedure GetValue(const aRow, aCol: Integer): Integer; strict private function fValidCoord(const aRow, aCol: Integer): Boolean; end; ... procedure TMyClass.GetValue(const aRow, aCol: Integer): Integer; begin if not fValidCoord(aRow, aCol) then raise EWrongCoord.Create("....."); ... end;

> Суслик © (23.02.07 11:47) [76]

> всегда объявляю предка для исключения, который свойственнен текущей
> библиотеке или классу

Здесь то же самое. EMatrixError и есть то самое исключение, которое свойственно текущей библиотеке. Если в каких-то случаях нужна более подробная конкретизация - плодим его потомка.

> пример практической пользы наследования от EMathError.

Насколько я понял, библиотека Matrix по сути своей - математическая. Значит, помимо ее собственных исключений при работе с ней могут возникать и другие математические исключения (переполнение, деление на ноль и т.п.) - и все они потомки EMathError. Поэтому, если EMatrixError тоже отнаследовать от EMathError, то юзер, не теряя возможности отлавливать конкретные исключения, получает еще и возможность отлова разом всех математических исключений (в том числе, и исключения самой библиотеки) c их единой обработкой (если в данном месте кода юзеру конкретизация не нужна):
... except on E: EMathError do обработка end;
Если же наследовать EMatrixError от общего Exception, то в данном примере обязательно пришлось бы писать повтор:
... except on E: EMatrixError do обработка; on E: EMathError do та_же_ самая_обработка; end;
А при наследовании от EMathError обязательность повтора исчезает. Можно делать и так, и так - что в данном месте требуется, то и делаем. И говорим "спасибо" автору, позаботившемуся о гибкости и удобстве использования своей библиотеки.
:о)

> Loginov Dmitry (22.02.2007 23:56:13) [73]

Даже не надейся, слишком самоуверен.

Free() Найти похожие ветки