Трюки в Delphi

← →
Rouse_ © (2014-04-24 18:36) [40]

> junglecat (24.04.14 18:34) [39]

Между прочим язык - огонь, только OnErrorGoToNext чего стоит, все try нервно курят в сторонке :)

← →
Ega23 © (2014-04-24 18:55) [41]

> 5*N строк кода против 3 + 3*N

Кстати, о пцыцах. А много ли у вас такого кода, когда в одной процедуре-методе создаётся более трёх локальных объектов?

← →
vuk © (2014-04-24 19:02) [42]

to Rouse_ © (24.04.14 18:30) [36]:

> Человек, настолько уверенный в своей правоте при применении
> данного подхода давным давно должен вообще отказаться от
> использовании try..finally, ибо зачем?

Сопцтвенно, например, FastReport наполовину так и написан. Типичное оттуда:

TempStream := TMemoryStream.Create; TempStream.CopyFrom(Stream, n - Stream.Position); TempStream.Position := 0; p.Picture.Graphic.LoadFromStream(TempStream); TempStream.Free;
Ну и несколько free в одном finally - тож в ассортименте.

← →
junglecat (2014-04-24 19:06) [43]

> Сопцтвенно, например, FastReport наполовину так и написан

видимо, Fast - не оттого, что быстро работает, а быстро написан

← →
Kerk © (2014-04-24 19:11) [44]

try/finally - это неожиданно больной вопрос. Я даже не ожидал :)

У меня в SourceOddity есть проверка на то, чтоб объект создавался вне try/finally блока. Но реально многие просят сделать исключение для случаев, когда перед этим есть присваивание nil. Вот все думаю, проявить принципиальность или пойти на поводу :)

← →
Rouse_ © (2014-04-24 19:19) [45]

> Вот все думаю, проявить принципиальность или пойти на поводу :)

Не порть хороший продукт - откажу в тестировании :))))

← →
Rouse_ © (2014-04-24 19:20) [46]

> откажу в тестировании :))))

Щас это называется модным словом - введу санкции :)))))))))

← →
Владислав © (2014-04-24 19:35) [47]

Rouse_ © (24.04.14 18:30) [36]

Надцать лет назад у нас возник спор по этому же поводу с jack128, если мне склероз не изменяет. С тех пор, видимо, ничего не изменилось. Раньше я тоже Вашего мнения придерживался.

По пунктам выскажу свое мнение. Обратите внимание, не ради спора, а ради расширения кругозора.

1. Читаемость затруднена только тому, кто не знает такую конструкцию. Некоторые начинающие вообще не знают про конструкцию try finally, но это не повод ее не применять.
2. То есть код вида:
// Получаем ресурс. try // Работаем с ресурсом. finally // Освобождаем ресурс, но при этом происходит исключение. end;
вполне допустим для утечек памяти, а обсуждаемый код для утечек не допустим? Причину допустимости утечек памяти в некоторых случаях назовите, пожалуйста?
3. Вопрос был не про умные указатели. Не в тему пункт.
4. Тут немного неясно. Насколько часто в деструкторе возникают утечки памяти, которые постоянно нужно разыскивать. Может пересмотреть подход к исключениям в деструкторе?
5. Вообще мимо. Настолько не в тему, насколько предложение отказаться от классов.
6. А тут совсем "молоко". Количество строчек кода было плюсом, а не минусом.

← →
Rouse_ © (2014-04-24 20:03) [48]

> Причину допустимости утечек памяти в некоторых случаях назовите,
> пожалуйста?

Так вопрос не стоял - утечки памяти не допустимы априори, а вот допускать новые, из-за неверно написанного кода, есть глупость.
Это кстати ответ на пункт 4.

← →
Ega23 © (2014-04-24 20:41) [49]

> Вот все думаю, проявить принципиальность или пойти на поводу :)

Сделай чекбокс. Галочка включена - иди. Выключена - не иди.
Состояние галочек, разумеется, сохраняй в ini-файл.

← →
Виктор1985 (2014-04-24 21:01) [50]

> Rouse_ © (24.04.14 18:30) [36]

Зачем вообще может понадобится проектировать деструктор так что бы там исключения поднимать? Объект когда умирает нужно давать ему спокойно умереть, он же больше не нужен.

В С++ если мне не изменяет память вообще от исключения в деструкторе рантайм падает, и живут неплохо, с утечками справляются.

Ну а по поводу стандартных исключений типа OutofMemory, которые могут возникнуть в деструкторе, если уж такое случилось то все равно как приложение умрет.

← →
Rouse_ © (2014-04-24 21:09) [51]

> Виктор1985 (24.04.14 21:01) [50]
> Зачем вообще может понадобится проектировать деструктор
> так что бы там исключения поднимать?

А кто сказал что кто-то его так проектирует? 0_о

← →
Владислав © (2014-04-24 21:28) [52]

"А кто сказал что кто-то его так проектирует? 0_о"

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

← →
Rouse_ © (2014-04-24 21:40) [53]

> какой смысл заботиться об утечках памяти?

Пункт 4.
Объясняю на пальцах, есть приложение и 3 объекта реализованных вот таким кривым способом, как показано выше + подключенный FastMM.
Приложение уходит бетатестеру.
Происходит падение в деструкторе первого класса FastMM показывает утечку по всем трем. Дальше объяснять?

← →
Владислав © (2014-04-24 21:51) [54]

Не стоит дальше. Дальше понятно. Дальше смотрим в лог исключений и ремонтируем косяки в своей программе. После ремонта косяков пункт 4 становится неактуальный.

← →
Rouse__ (2014-04-24 21:54) [55]

Это только первый этап, а теперь у нас приложение целиком криво написанное, на выходе мегабайты логов из-за падений, как будем вычислять проблемное место? А ведь все просто, будучи правильно написанным, лог выведет только проблемные классы, не более того

← →
Владислав © (2014-04-24 21:57) [56]

"А ведь все просто, будучи правильно написанным, лог выведет только проблемные классы, не более того"

Саш, а правильно написанное часто в деструкторе падает? ;)

← →
Rouse__ (2014-04-24 22:02) [57]

50/50 либо падает либо нет :)

← →
Владислав © (2014-04-24 22:09) [58]

Саш, да ну нафиг. Есть у Вас пример из реальной программы?

← →
Rouse__ (2014-04-24 22:16) [59]

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

← →
Rouse__ (2014-04-24 22:19) [60]

Вон сегодня с женькой решали, код простой topendialog создали отобразили, передали результат функции разрушаем - оппа, у 148 человек за три месяца на деструкторе диалога AV, сиди и думай - откуда?

← →
Rouse__ (2014-04-24 22:20) [61]

Причем пользователей у нас за 200 тыщ а возникло только у 148-и за такой длительный период

← →
Rouse__ (2014-04-24 22:22) [62]

Точнее не у 148 пользовотелей, а всего 148 раз :))

← →
Владислав © (2014-04-24 22:23) [63]

Не верю. Я, конечно, не скажу, что я в этом вопросе принципиален и категоричен, понимаю, что "всякий овощ...", но 50/50 исключения в деструкторе? Не верю. :)

← →
Владислав © (2014-04-24 22:25) [64]

"Вон сегодня с женькой решали, код простой topendialog"

Занимательно. Нашли причину? Поделитесь информацией.

← →
Rouse__ (2014-04-24 22:27) [65]

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

← →
Rouse__ (2014-04-24 22:28) [66]

Еще не решили ибо не знаем даже с какой стороны подойти и как возпроизвести

← →
Rouse__ (2014-04-24 22:29) [67]

50/50 - это шутка из анекдота про блондинку и динозавра :)

← →
Ega23 © (2014-04-24 22:34) [68]

Удалено модератором

"50/50 - это шутка из анекдота про блондинку и динозавра :)"

Ясно. Получается, на несколько обсуждаемых случаев (пока два, может еще вспомните), пожалуй, несколько миллионов finally? Говорит ли это о том, что конструкция не имеет права на существование? ;)

"Я - д"Артаньян!"

Это вообще самый серьезный трюк. Это почти что кнопка "Сделать все хорошо". :)

← →
Rouse__ (2014-04-24 23:08) [70]

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

← →
Rouse__ (2014-04-24 23:09) [71]

Но если смотреть по багтрекеру их конечно на порядок больше, всеж не упомнить

← →
Rouse__ (2014-04-24 23:16) [72]

Вот еще интересная ошибка, но уже не с деструктором связанная. Мы сохраняем данные чере ixmldocument на ворме edit вводим в него произвольный текст а потом нажимаем ctrl+Shift+6 и получившийся текст пишем в атрибуты узла после чего сохраняем xml. Собственно все - теперь этот документ не откроется из-за ошибки загрузки.
Msxml не будет экранировать этот символ, что есть глюк.

Ну в итоге все равно "всякий овощ...". Понятно, что думать нужно...
Спасибо за дискуссию! :)

Удалено модератором

← →
Rouse__ (2014-04-25 00:03) [76]

Удалено модератором

← →
junglecat (2014-04-25 10:42) [79]

Удалено модератором

Трюки в Delphi Найти похожие ветки