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

Цитата korvin @ 13.02.13, 17:16

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

Справка рекомендует Free. Если нужно не просто уничтожить объект, а еще и занулить ссылку на него, то можно FreeAndNil.

PS: Насколько я понимаю, --Ins-- выступает не против FreeAndNil как такового, а против самой практики повторного использования ссылок на объекты или, скорее, злоупотребления такой практикой

Цитата leo @ 13.02.13, 17:25

PS: Насколько я понимаю, --Ins-- выступает не против FreeAndNil как такового, а против самой практики повторного использования ссылок на объекты или, скорее, злоупотребления такой практикой

Типа того... Для меня привычно, когда объект и ссылка на него живут одинаковый промежуток времени. А когда оно так, то и нет необходимости проверять что-либо на nil

Цитата jack128 @ 13.02.13, 12:24

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

Отчасти соглашусь. Но тут есть два момента:
1. Порог вхождения. В С++ он выше.
2. C++ сейчас эволюционирует (достаточно активно) в сторону сглаживания острых углов. В частности, проблема с "дикими" указателями (а это одна из основных проблем) в новом стандарте практически решена, хотя и средствами библиотеки (std::unique_ptr/std::shared_ptr/std::weak_ptr).
3. Для того, чтобы добраться до серьёзных неявностей в языке, скилы нужно прокачать достаточно сильно. Новичку на них наступить практически нереально.
4. На C++ свет клином не сошёлся. Есть и другие современные языки, лишенные подобных проблем с дизайном.

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

Нет, я тебя просил дать определение, что такое хорошо, а что такое плохо.

Ну да. А я тебе дал критерий оценки. Один из.

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

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

И какова же реальная выгода от раздельного конструирования (или разрушения), если, вон, leo пишет, что использовать такие хитрые способы инициализации приходится очень даже не часто? Я понимаю дизайнерское решение, в котором максимально упрощается основной workflow, а для special case'ов предусматриваются обходные пути. Это нормально и правильно. Но вот так ли это в данном случае?

Цитата Flex Ferrum @ 13.02.13, 19:28

На C++ свет клином не сошёлся. Есть и другие современные языки, лишенные подобных проблем с дизайном.

Подробнее!

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

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

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

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

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

А разве Delphi - это не среда программирования для школьников и студентов младших курсов? Или термин "формошлёпство" - это про какую-то другую среду разработки?

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

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

Уважаемый leo, "Дядя Сэм" делится с тобой собственным архитектурным опытом.

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

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

У меня есть статистика (реальная, на собственном опыте) по тому, сколько стоят те или иные архитектурные косяки. Мне этого достаточно для оценки решений.

Цитата leo @ 13.02.13, 16:01

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

Эммм... Если я вставляю к себе в машину движок, то я предполагаю, что мне не надо вставлять в него коленвал. Всё, что от меня требуется - это соединить двигатель с другими компонентами автомобиля. Но сам движок - во вполне операбельном состоянии. И далее: когда я отдаю покупателю автомобиль, предполагается, что покупателю не надо на эвакуаторе тащить его в сервис, чтобы там ему гайки докрутили и топливопровод смонтировали. Клиент предполагает, что на автомобиле уже можно ездить.

Цитата leo @ 13.02.13, 16:01

Нужен пример вызова виртуальных методов в конструкторах? Да в том же TCustomForm.Create юзается виртуальный спец.конструктор CreateNew, который лишь инициализирует "собственные" поля формы, а все "накиданные" на нее компоненты создаются позже загрузкой из ресурсов в основном Create.

Внезапно в том же Qt обходятся без таких вот вывертов, и это как-то работает. Странно, правда?

О, еще один опус не заметил (при беглом просмотре 485 стр. )

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

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

Ой как вынуждены, как вынужден-ны!!! Чур меня, чур, нечистая пасквильная сила! Дядя С++эм, спаси нас, грешных!!!

PS: Я как-то не привык делить мир на "ваших и наших" и с равным интересом заглядываю как в дельфийские "общие вопросы", так и в ваш бывший "чистый С++". И как-то складывается Ощущение №Y, что в приплюснутом разделе "вынужденных защищаться от самих себя" гора-аздо больше, нежели в дельфийском (даже с учетом порпавки на "загнивание" последнего). Видимо, чтобы достичь высот отцов-основателей типа Страус-Трупа и Ko нужно не один пуд соли съесть, и не одну "ногу отстрелить по самую шею"

Добавлено 13.02.13, 19:51

Цитата Flex Ferrum @ 13.02.13, 19:44

Можешь в меня сейчас кидаться мокрыми тряпками...

Извини, прямо сейчас не могу - режим-с, баиньки пора

Цитата leo @ 13.02.13, 19:46

Видимо, чтобы достичь высот отцов-основателей типа Страус-Трупа и Ko нужно не один пуд соли съесть, и не одну "ногу отстрелить по самую шею"

Эммм... Для того, чтобы начать нормально писать - достаточно вменяемого букваря. Вопрос в другом: есть ли такие? А на счёт "достижения высот", тут вот в соседней теме сцыль http://blogs.embarcadero.com/vsevolodleono...ply_friendship/ кинули. Очень занятный взгляд на предмет со стороны делфи-гуру. Или он не очень гуру?

Цитата leo @ 13.02.13, 19:46

Ой как вынуждены, как вынужден-ны!!!

А что, нет? Не вынуждены? Ну с Ins'ом понятно - он следит за своим кодом. А вот откуда берутся упомянутые тут CSG-сентенции в стиле "всегда пользовать FreeAndNil"? Ну не с потолка ведь? К слову сказать, ни в одном гайде по C++ ты не найдёшь ничего в стиле: "Всегда зануляйте поля в деструкторах классов!!!". Потому что для С++-ника это звучит как полная ересь.

Цитата

"Всегда зануляйте поля в деструкторах классов!!!"

Ну... как бы, если вдруг мы используем placement-new, когда деструктор вручную зовется, то было бы не вредно занулить. Скажем, хендлы, что бы по второму разу не нароком не закрыть. Или указатель, который только что ухерачил.. но в любом случае смарт-обертки над всем этим безобразием 100% спасают. А то вдруг какая то сотона позовет деструктор ВТОРОЙ РАЗ?!!

Сообщение отредактировано: Бобёр - 13.02.13, 20:03

Цитата Flex Ferrum @ 13.02.13, 19:44

У меня есть статистика (реальная, на собственном опыте) по тому, сколько стоят те или иные архитектурные косяки. Мне этого достаточно для оценки решений.

Флееекс, я думаю не надо сводить беседу к меренью пузиками, опыт то у тебя безусловно есть, но не в использовании обсуждаемых принципов. А у меня он - как раз в них. И если я говорю, что профит больше чем цена, твои сомнения тут весьма подозрительны. В чем профит? В гибкости самого подхода полиморфного конструирования

Добавлено 13.02.13, 20:12

Цитата Flex Ferrum @ 13.02.13, 19:44

А разве Delphi - это не среда программирования для школьников и студентов младших курсов?

Нет, это вполне годный профессиональный инструмент, способный решать профессиональный задачи в рамках своей компетенции.. Удивительно!

Цитата Бобёр @ 13.02.13, 20:02

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

Ну не в деструкторе же. Который зовётся.

Цитата --Ins-- @ 13.02.13, 20:09

но не в использовании обсуждаемых принципов.

Каких? Двухфазной инициализации? Я на её базе фреймворк проектировал. Применение такого подхода было продиктовано рядом требований (от которых нельзя было отказаться), и не могу сказать, что пользователи фреймворка были сильно рады такому раскладу.

Цитата

Ну не в деструкторе же. Который зовётся.

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

Цитата Бобёр @ 13.02.13, 20:28

но вот когда пользователю класса надо явно вызывать ->~, то имхо, это полезно, ибо спасает.

Хм... Дважды явно позвать деструктор для куска памяти? Этот баг надо ловить какими-то другими методами. Далеко не всё ты занулить сможешь.

Бобёр, операторы new и delete для того и придумали, чтобы избавить людей от ошибок использования неинициализированных объектов. Программисту дали инструменты в лице конструкторов и деструктора, чтобы он во вполне конкретных местах описал, как правильно инициализировать и уничтожать объекты выдуманного им типа, и компилятор знает, где искать эти инструкции. Для объектов не в dynamic storage компилятор способен сам определить, когда их вызывать, а вот для dynamic storage он сам не в состоянии. Всякие там malloc()/free() тут не помогут, т.к. будучи C-инструментом, имея дело с void* и работая в ран-тайм, ничего не могут автоматизировать в принципе, ибо не имеют никакой информации о типах и следовательно конструкторaх/деструкторах.
Операторы new и delete, будучи сущностями периода компиляции, дают необходимые компилятору точки отчёта о начале и конце времени жизни конкретного объекта конкретного типа. И их задача - не дать разорваться этим парам: выделить+сконструировать и деструктировать+освободить. Когда же речь заходит о placement new и dtor explicit call, то она заходит именно что о необходимости разорвать эти пары. О явном намерении программиста взять в свои руки управление этими тандемами. Об осознанном решении программиста. По крайней мере, с его точки зрения осознанном. Если он накосячит, компилер умыл руки. А что значит "накосячит"? Например, нарушит принципы модели объектов, принятые в C++ и описанные в Стандарте. Так что взялся за гуж dtor explicit call, не говори, что не дюж, позволив повторно вызваться деструктору.

Цитата Flex Ferrum @ 13.02.13, 19:44

Внезапно в том же Qt обходятся без таких вот вывертов, и это как-то работает. Странно, правда?

а MOC - это выверт, или Ъ приём программирования?

Положа руку на сердце, работая верификатором, приходилось писать подобное:

SomeClass *testObj = new unsigned char[sizeof(*testObj)];
 
memset(testObj, '\7B', sizeof(*testObj));
new(testobj)SomeClass(/ ... / );
findPADs(testObj);
 
/* ... */
 
testObj->~SomeClass();
checkFieldsFinalValues(testObj);
 
delete[] reinterpret_cast<unsigned char*>(static_cast<void*>(testObj));

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

и даже так приходилось

{
  SomeClass testObj;
 
  testObj::~SomeClass();
  memset(&testObj, '\7B', sizeof(testObj));
  new(&testobj)SomeClass(/ ... / );
  findPADs(testObj);
 
  /* ... */
 
  testObj::~SomeClass();
  checkFieldsFinalValues(testObj);
 
  new(&testobj)SomeClass;
}

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