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

[leo]

Цитата Flex Ferrum @ 13.02.13, 12:05

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

Как раз в этой самой реальной жизни объекты очень часто и не конструируются "до операбельного состояния". Какой смысл при создании некого контейнера (типа TStringList, TMemoryStream и т.п.) сразу выделять память под хранилище неизвестно чего и скоКа?! Аналогичных примеров, когда нечто создается только "по требованию" можно привести вагон с маленькой тележкой. Отсюда и проверки либо указателей, либо связанных с ними параметров типа Count, Size, HandleAllocated и т.д. и т.п. А если объект предусматривает еще и некоторую очистку (Clear) с освобождением излишков памяти, то он ес-но должен и соотв.указатели и связанные с ними параметры занулять - "из этого и растут ноги" у нормального FreeAndNil (а не из ваших досужих домыслов )

Добавлено 13.02.13, 13:34
PS: --Ins--, не перегибай палку! По крайней мере, "Найди в коде VCL хоть одну ..." - это явный перебор

Добавлено 13.02.13, 13:43

Цитата Flex Ferrum @ 13.02.13, 12:14

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

А должен? Типо: среда программирования для детских дошкольных учреждений Сколково и Руснано?

Цитата Flex Ferrum @ 13.02.13, 12:14

Собственно, характеристика error prone в этом и заключается - сколько у тебя шансов отстрелить себе ноги по шею.

У тебя есть статистика, кто больше себе ног отстрелил? Или это все те же домыслы?

Ощущение №X, о котором я уже упоминал - заветы КПСС в действии, Дядя Сэм со товарищи учат все "недоразвитые" страны и народы, как нужно жить "правильно", чтобы не "отстреливать себе ноги" на каждом шагу

Сообщение отредактировано: leo - 13.02.13, 13:47

[D_KEY]

Цитата leo @ 13.02.13, 13:27

Как раз в этой самой реальной жизни объекты очень часто и не конструируются "до операбельного состояния".

Надо что-то менять в такой жизни

Цитата

Какой смысл при создании некого контейнера (типа TStringList, TMemoryStream и т.п.) сразу выделять память под хранилище неизвестно чего и скоКа?!

Может и иметь. Даже если не имеет, контейнер без элементов так же имеет вполне себе "операбельное состояние".

[leo]

Цитата D_KEY @ 13.02.13, 13:45

Может и иметь. Даже если не имеет, контейнер без элементов так же имеет вполне себе "операбельное состояние".

Тебе лишь бы возразить. Только в данном случае ты не мне возражай, а своему "стороннику\соратнику" Flex Ferrum-у, поскольку как ни крути, а если чего-то еще нет, то без проверки условий (как ты их не прячь и не заворачивай в разные классы-фантики) - по любому не обойтись, и это нормальная практика "в реальной жизни"

[--Ins--]

leo, по моему на другом форуме как-то задавались вопросом об использовании FreeAndNil в Vcl. Насчитали что то около трех раз. И точно не в тех случаях о которых тут говорят

[Chow]

Цитата --Ins-- @ 13.02.13, 12:10

Найди в коде VCL хоть одну такую проверку? Сомневаюсь, что найдешь.

Шутите?!

Прикреплённая картинка

Добавлено 13.02.13, 14:19
355(!) и это - ФАЙЛОВ

[Shaggy]

Цитата --Ins-- @ 13.02.13, 14:00

Насчитали что то около трех раз. И точно не в тех случаях о которых тут говорят

это не так...
около сотни
местами создаётся впечатление, что код писал какой-то засланный казачёк, либо очень "одарённая" личность

[Chow]

А если с натяжкой считать VCL'ем еще и сорсы TChart'а (который, базовый, входит в поставку) - то и того более.
(Как раз на нем я и накололся)

Да, кстати.
Глянул - львинная их доля таки в

destructor TXxx.Destroy;

[Shaggy]

Цитата Chow @ 13.02.13, 14:19

355(!) и это - ФАЙЛОВ

это во всех сырцах

[leo]

Цитата --Ins-- @ 13.02.13, 14:00

leo, по моему на другом форуме как-то задавались вопросом об использовании FreeAndNil в Vcl. Насчитали что то около трех раз. И точно не в тех случаях о которых тут говорят

Вообще-то в #7246 речь шла не столько о FreeAndNil, сколько о проверках на nil - а этих проверок разумеется предостаточно, и это вполне нормально и естественно

[--Ins--]

Цитата Shaggy @ 13.02.13, 14:20

это не так...
около сотни

Да? Что-то значит напутал. Посвящу как-нибудь время изучить этот вопрос внимательнее

Цитата leo @ 13.02.13, 14:32

Вообще-то в #7246 речь шла не столько о FreeAndNil, сколько о проверках на nil - а этих проверок разумеется предостаточно, и это вполне нормально и естественно

Ну, как сказать - скорее да, естественно. Но в моем коде они все-таки встречаются довольно редко. Если я правильно понял описанный тобой случай - то я не сторонник создавать внутренние объекты по мере надобности, а предпочитаю создать их в конструкторе. Как раз для того, чтобы необходимость подобных проверок избежать

[leo]

Цитата --Ins-- @ 13.02.13, 15:03

Если я правильно понял описанный тобой случай - то я не сторонник создавать внутренние объекты по мере надобности, а предпочитаю создать их в конструкторе

Значит ты не работаешь с мега-гигабайтными массивами данных заранее неизвестного объема, или полагаешься на готовые TMemoryStream и т.п. По крайней мере TList, TStringList, TMemoryStream и т.п. никакую память под данные в конструкторе не выделяют, и правильно делают

Сообщение отредактировано: leo - 13.02.13, 15:11

[--Ins--]

Цитата leo @ 13.02.13, 15:10

Значит ты не работаешь с мега-гигабайтными массивами данных заранее неизвестного объема, или полагаешься на готовые TMemoryStream и т.п. По крайней мере TList, TStringList, TMemoryStream и т.п. никакую память под данные в конструкторе не выделяют, и правильно делают

Все правильно, но nil-ом пустому списку быть необязательно

[leo]

Цитата --Ins-- @ 13.02.13, 15:16

Все правильно, но nil-ом пустому списку быть необязательно

Не списку, как объекту-контейнеру, а его составной части TList.List. У TList даже собственного конструктора нет, и создается он "гол как сокол" весь "заниленный" (по кр.мере в D7). И метод Clear его также очищает "под чистую". (И к тому же Clear является виртуальным и вызывается в Destroy на (зло)радость нашим оппонентам - во-о, мы же говорили )
А что касается самого объекта TList, то разумеется его в большинстве случаев проще сразу создавать, т.к. он сам по себе "много каши не просит"

Добавлено 13.02.13, 16:39

Цитата Flex Ferrum @ 13.02.13, 11:51

С ним можно работать, вызывать его методы и т. п. В общем, это тот момент, когда объект становится операбельным для клиента.

В данном случае речь идет не о самостоятельном объекте, а лишь о "детали" другого более сложного объекта. Думаю не одному нормальному человеку не придет в голову на этапе сборки автомобиля бездумно "вызывать методы" только что установленного движка?! На этапе сборки целого от каждой детали требуется лишь незначительная часть ее свойств - соответствовать спецификации и "встать на место". Также при сборке м.б. не важен порядок и тем более завершенность сборки\установки отдельных деталей - колеса можно прикрутить как до, так и после навешивания дверей и т.д. Также при сборке чего-то могут быть предусмотрены некие внешние опции (виртуальные методы) - если все это допустимо и даже в порядке вещей в реальной жизни, то почему этого нельзя делать в ООП? (Про error-prone мы уже слышали - можно не повторяться)

Цитата Flex Ferrum @ 13.02.13, 11:39

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

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

Нужен пример вызова виртуальных методов в конструкторах? Да в том же TCustomForm.Create юзается виртуальный спец.конструктор CreateNew, который лишь инициализирует "собственные" поля формы, а все "накиданные" на нее компоненты создаются позже загрузкой из ресурсов в основном Create. И чё, нормальному человеку придет в голову переопределять этот CreateNew, не зная как он работает?! (Кстати и в самом CreateNew юзаются неявные вызовы виртуальных методов, в частности Visible => VisibleChanging, предусмотрительно вставленный в TControl для потомков). Да в большинстве случаев даже сам Create мало кто переопределяет и все довески пишут в обработчике события OnCreate, который вызывается заведомо после инициализации формы - по всем правилам С++, но только добровольно, а не принудительно . Ну а те, кто знает как работают CreateNew и Create могут позволить себе изменить порядок инициализации формы, в частности загрузку компонентов из ресурсов (например, добавить дешифровку\шифровку, загрузку из другого ресурса или внешнего файла и т.п.).

Сообщение отредактировано: leo - 13.02.13, 16:39

[korvin]

Я так и не понял, как же правильно уничтожать объект в делфи: Destroy, Free или FreeAndNil?

[Qraizer]

Цитата MyNameIsIgor @ 13.02.13, 12:59

Цитата trainer @ 13.02.13, 12:57

auto

Его никто не юзал. Только упоротые сишники - с ними можно не считаться.

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