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

Цитата

Сам в delphi работаю давно. Сначала использовал FreeAndNil, потом перешел на Free, и сейчас много использую именно Free. Но в последнее время (года 3-5) стали лезть не совсем понятные ошибки: программа работает нормально, а стоит ее завершить, сразу лезет Exception, обращение к несуществующему адресу. Сильно подозреваю, что если не обнулить ссылку, сборщик мусора при завершении программы пытается повторно освободить память. Интересно, что ошибки не лезут в мелких программах, но стоит программе разрастись, начинают лезть. Поэтому как минимум надо сначала Free, потом еще и := nil. В связи с вышеизложенным в последнее время стал возвращаться к использованию FreeAndNil, ошибки вылазить перестали.

http://www.gunsmoker.ru/2009/04/freeandnil-free.html

по поводу Clear из деструктора, а в плюсах как?? Деструктор там может быть полиморфным, а вызовы методов из деструктора - полиморфны???


[S]mike

var
  Obj: TMyObject;
begin
  Obj := TMyObject.Create;
  try
  finally
     // как ты тут предлагаешь освободить объект ??
  end;
end;

Цитата jack128 @ 11.02.13, 17:19

// как ты тут предлагаешь освободить объект ??

Просто Free.

Цитата --Ins-- @ 11.02.13, 16:52

В Java есть культ, что утечек не бывает и за памятью следить не надо А в Delphi есть культ - что следить надо самому и внимательно.

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

[S]mike почему не Destroy?

Цитата jack128 @ 11.02.13, 17:42

[S]mike почему не Destroy?

И ты, Джек, решил меня потроллить? Это ты к тому, что Free имеет бесполезную проверку на <> nil?

да, именно к этому

Цитата jack128 @ 11.02.13, 11:39

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

Причина на самом деле одна, а вот эти - её следствия.
В объектной модели Дельфей объект создаётся в два этапа: сначала вызывается конструктор класса, затем конструктор объекта. Первый обычно всегда одинаков, предоставляется ...ну пусть будет языком; грубо говоря, он уже создан без нашего участия. Его можно перекрыть, но очень редко, когда это требуется, ибо зануление всех полей, настройка PtoVMT итп обычно всех устраивает. Второй конструирует конкретный объект путём инициализации полей т.о., чтобы получить не конгломерат занулённых полей, а некое конкретное, требуемое нам, состояние экземпляра класса. Естественно, раз объект жив уже после первого этапа, конструктор объекта вполне может быть виртуальным, если что-то в нём пошло не так, вызов деструктора при исключении из конструктора вполне закономерен, экземпляр класса суть монолит, т.к. из-за возможности виртуальных конструкторов объекта ни один из уровней в иерархии нельзя рассматривать изолировано от остальных, хоть базовых, хоть производных, итп.
Уже пришли в выводу, что такая двухступенчатая процедура вполне имеет право на жизнь, и хоть и не настолько эффективна, как плюсовая, по производительности, но в плане удобства её использования довольно привлекательна. Отсюда же растут ноги у BeforeXXX/AfterYYY, отсюда же виртуальность конструкторов итп. И эта модель тем более выглядит логичной, если взять за базу тезисы:

• единый предок для всех классов (для того самого обобщённого конструктора класса, а также для RTTI);
• всё на позднем связывании, а значит никаких storage classes, окромя dynamic (то бишь попросту всё в хипе);
• ссылочная семантика во избежание граблей (тем более, что коли всё в хипе, окромя как по указателю и ссылке, объект всё равно не получить).

Плюсовая модель создаёт объект в один этап: вызывается конструктор. Всё. Язык тоже предлагает предопределённые конструкторы, и они в целом выполняют ту же роль, что конструкторы классов в Дельфях, но поскольку процесс конструирования не делятся на этапы, то для создания инвариантов для экземпляра класса (для чего Дельфи предоставляет конструкторы объектов) они в общем случае не подходят. Поэтому иметь собственные конструкторы взамен предоставляемых является распространённой практикой. И в результате мы получаем то, что не нравится многим дельфистам, потому что они привыкли в сервису, зато нравится нам, потому что мы не привыкли к диктатуре со стороны языка.
Корень большей части противоречий и причиной холиваров является то, что дельфисты и плюсники друг друга зачастую просто не понимают. Дельфисты вообще редко вспоминают о конструкторах класса, ибо их существование обычно не заставляет на себя обращать внимание, зато очень часто они работают с конструкторами объектов. Потому и называют их просто конструкторами, чем сбивают с толку плюсников, ибо они отождествляют конструкторы с (в дельфийской терминологии) с конструкторами классов и потому тупо не понимают, ни как конструктор может быть виртуальными, ни как объект может жить до вызова конструктора, ни итд, ни итп. Соответственно когда дельфисты начинают хихикать и тыкать пальцем в BeforeXXX/AfterYYY, мол, смотрите, как у нас всё круто, плюсисты крутят фигу, и тычут пальцем в фабрики, на что те крутят тем же пальцем у виска, мол, ну и изобретатели же гамаков с педалями себе на жо ...э-э-э, голову, эти плюсисты. Понятно, думаю, к чему я это всё. В общем получается как у кошек с собаками - у тех конфликты по той же причине: одинаковые действия означают разные вещи. Тут мы вроде бы даже договорились называть конструкторы объектов инициализаторами (ибо на плюсах таковыми будут именно что отдельные методы; хотя в C++11 появилось понятие делегирующих конструкторов) или же полным наименованием "конструктор объекта" или там "... класса", но похоже на то, как будто договорились только плюсисты, а дельфисты намерено саботируют сие, чтобы почаще, подольше и пожирнее потролить.
Собственно отсюда же и следуют вот те два тезиса, jack128. С позиции дельфистов судить не берусь. А вот с позиции плюсника могу. Получается примерно следующее.
В Дельфи есть одна большая на весь язык фабрика, чьё дефолтовое поведение документировано, и которая позволяет себя кастомизировать на разных участках. Чтобы это было возможным, пришлось кое-чем пожертвовать. В результате любая программа платит этой фабрике, и обойти это никак нельзя: все объекты только в хипе, они всегда полиморфны, их использование вне парадигмы ООП затруднительно (если вообще возможно), инвариант "всё обнулено" крайне желательно добавлять к своим инвариантам и всячески поддерживать как один из возможных, что выливается в постоянный его контроль в каждом методе, особенно виртуальном. Последнее можно обойти, но для этого придётся кастомизировать конструктор класса, что с точки зрения дельфийной модели ООП является исключительной ситуацией в дизайне приложения, потому вряд ли является рекомендованной к повседневному использованию методикой.
В Плюсах нет фабрики вообще. Она просто не нужна, потому что потребность в ней возникает редко, а когда возникает, её можно создать по конкретно тем потребностям, каковые побудили её создать. И требуется это действительно редко, наверное так же редко, как, если верить заверениям --Ins---а, возникает потребность в кастомизации конструктора класса, BeforeXXX/AfterYYY, эцетера в Дельфи. В результате программы на Плюсах не платят за неиспользуемое, объекты при необходимости могут быть спроектированы очень лёгкими, чья сфера применения больше не ограничивается только лишь ООП. Да что там говорить: классы в Плюсах используются в контексте ООП хорошо, если в трети случаев их применения. Объекты не монолитны, ответственность между уровнями иерархии прекрасно разделяется и контролируется, полная свобода в выборе инвариантов... что я там ещё забыл упомянуть... ну понятно, в общем, к чему это всё.
Самое неприятное в таком положении вещей то, что нельзя сказать, что одна из моделей лучше или хуже другой, что как раз не хотят понимать участники холиваров. У этих моделей разные философии, и их дизайн отвечает наиболее среднестатистически распространённым сценариям их применения. Если взять хороший плюсовый код и тупо перенести в Дельфи, получим говнокод; если взять хороший дельфийный код и тупо перенести в Плюсы, получим тоже говнокод. (Пользователям Билдера отдельный привет, у тех вообще две разные философии присутствуют одновременно, и им следовать надо тоже одновременно. Полный алес, короче.) Разные объектные модели требуют и разных методов дизайна приложения. То и как что-то делается в Дельфи, делается и на Плюсах, только те же цели достигаются иначе. И наоборот. Скажем, потребность в полиморфности конструкторов объектов практически никогда не возникает, т.к. глубокой обратной связи между базовыми и производными классами плюсисты предпочтут стратегии поведения или прокси-классы свойств. А простенькую фабрику с автоинициализацией экземпляра после конструирования дельфист просто выкинет, запихнув автоинициализацию в AfterConstruct. Итп.
Прикол-то в том, что в подавляющем большинстве случаев плюсисты проектируют на классах, которые с точки зрения Дельфи не являются ООП-объектами, потому для них выглядит дикостью передача объектов по значению, размещение их на стеке итп. Тот факт, что плюсисты, если оно им надо, могут получить всё то же, что Дельфи даёт искаропки, во внимание не принимается, да только это дельфийное искаропки для принципов плюсового дизайна не является характерным использованием плюсовой объектной модели. Да, для этого придётся кое-что написать руками или "стырить", например, из буста, но мы согласны заплатить этим, ибо в целом так нам получается дешевле. Но то же верно и наоборот. Дельфист тоже сможет получить всё то же, что и плюсист, и ему тоже придётся что-то там для этого написать. И он тоже будет согласен заплатить за это тем оверхедом, который диктует язык. Просто в ряде случаев эта плата будет больше. К примеру лёгкого объекта в Дельфи получить просто нельзя, придётся пользовать "пользовательский тип", со всеми вытекающими "неудобствами", каковые следуют из отказа от базовой философии объектной модели. Но это ему не критично, ибо сама модель разрабатывалась как раз для упрощения пользования ею во вполне определённом окружении, и вот в этом окружении она как рыба в воде. Потому дешевле для Дельфей - вот так, как искаропки. Плюсники же такого себе не могут позволить, у них другие ориентиры на дизайн.

Жесть какая. Qraizer -- убийца холиваров =))

Qraizer
поясни, что ты называешь конструктором класса (class constructor ???)?? в дельфе это понятие появилось относительно недавно, это обчная процедура, которая авматом вызывается при старте приложения. Обычно используется для инизиализации всяких глобальных переменных/class var связанных с классом. ПО контексту ты вроде что то другое имеешь в виду.

Да, забыл ещё P.S.

P.S. Исключение в конструкторе - это более чем нормально. Это более нормально, чем его отсутствие. Задача конструктора (объекта) - создать объект (экземпляр класса). Это значит, что если невозможно по каким-то причинам настроить инварианты - объекту не быть: не(!)быть(!), точка, жирная. Исключение из конструктора - единственно праведная политика, позволить существовать объекту без инвариантов с нацепленным АПИ по опросу его валидности - ...это лукавый, други, no other ways.

Добавлено 11.02.13, 18:05
jack128, не помню. Кто у вас создаёт из кучи мусора на месте хипового стораджа занулённый регион памяти с настроенной VMT? CreateInstance()? Значит он.

Сообщение отредактировано: Qraizer - 11.02.13, 18:05

Цитата Qraizer @ 11.02.13, 18:03

CreateInstance()? Значит он.

классовый вирутальный метод NewInstance(). ОК.

Цитата Qraizer @ 11.02.13, 17:48

Плюсовая модель создаёт объект в один этап: вызывается конструктор. Всё. Язык тоже предлагает предопределённые конструкторыаналоги NewInstance, и они в целом выполняют ту же роль, что конструкторы классов в Дельфях, но поскольку процесс конструирования не делятся на этапы,

Можно на пальцах:

struct Base {
  Base() {std::cout << "Base ctor";}
  virtual ~Base() {}
}
struct Child { Child() {std::cout << "Child ctor";}}
 
auto c = new Child();

в какой момент будет вызван сишный аналог NewInstance ??

Сообщение отредактировано: jack128 - 11.02.13, 18:21

Цитата jack128 @ 11.02.13, 17:19

по поводу Clear из деструктора, а в плюсах как?? Деструктор там может быть полиморфным, а вызовы методов из деструктора - полиморфны???

Нет. Деструктор предка вызывается когда потомок уже уничтожен и потому вызов не полиморфный - прямая аналогия с деструкторами.

Цитата jack128 @ 11.02.13, 18:15

в какой момент будет вызван сишный аналог NewInstance ??

Не до конца уверен, что понимаю Qraizer'а, но судя по всему он имел в виду operator new.

Цитата [S]mike @ 11.02.13, 16:29

Сейчас Ник Ходжес читает старую-престарую книгу Head First Design Patterns для Джавы (и я тоже, кстати, ее читаю - отличная книга). И ведет блог о своих впечатлениях, дает примеры реализации паттернов на Дельфях. И его изыскания пользуются популярностью: http://smartmobilestudio.com/2013/02/08/de...terns-observer/

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

Цитата Flex Ferrum @ 11.02.13, 18:46

Справедливости ради отмечу, что джависты дружно фапают на паттерны.

Да у них на собеседованиях даже скука - всё про паттерны.
Ещё бы - язычок то нищий. То ли дело плюсы - а где здесь неопределённое поведение, а?