OberonCore

Здравствуйте.

Скажите пожалуйста, где можно почитать об особенностях реализации ООП в Delphi/Free pascal
Интересует какой подход более эффективен (по быстродействию, по объёму кода и т.п.)
Как я понимаю, сейчас есть две ветки ООП


и второй


Как писать правильно ?

Несколько замечаний:
- ключевое слово property поддерживается только для class'ов;
- аналогично с interface'ами;
- про поддержку конструкторов и деструкторов не помню;
- все class'ы явно или неявно унаследованы от типа TObject, для object'ов общего предка нет. Посмотрите методы TObject, увидите там базовую поддержку COM.
По сути, object сильно похож на Обероновские расширяемые записи.

На сколько я знаю, первый вариант - это для обратной совместимости, так было раньше. Сейчас Class, как правильно сказали наследник от TObject. Для создания используется конструктор: MyObj:= TMyObj.Create(), который можно переопределить. В качестве деструктора переопределяют Destroy, но прямо его не вызывают, а вызывают всегда TMyObj.free

На счет похожести на записи оберона, не согласен, и синтаксис другой и значительно более громоздкий и живут только в динамике.
Насчет почитать, даже не знаю много всего, для начала наверно Архангельский подойдет. Много самых разных материалов на "Корелевстве Делфи" http://delphikingdom.com/

Классы - это такая фиготень, которая располагается только в heap-е, обладает счетчиком ссылок, обнуление которого и есть причина для удаления. Которое происходит сразу же, без раздумья
В общем, ref-counting, вместо сборки мусора. Классы в локальных переменных отслеживаются корректно - уничтожаются (в смысле - уменьшается счетчик ссылок) по выходу. Даже если мимо пролетает исключение (за возможность которого ты ни сном ни духом) - перехватит, и обработает (та еще история, между прочим...)

У объекта - нифига такого нет. Просто синтаксически обагащенная структура данных (не ну vmt у нее конечно есть...). Все на ответственность программиста. Чтобы не расслаблялись

Неправда Ваша.
Весь KOL собран на Object, а уж сколько там property - и не сосчитаешь. Собственно, использовние property - ключевая фишка в KOL.
Установил какой-нибудь Align := caLeft - и к обработчику сообщений пристегивается килобайтный хэндлер (скажем AlignChildrenProc). Что значит пристегивается - это труд обработчика property для объекта TControl, определенного в KOL.
Ну и если никогда в твоем коде нет установок этого свойства - твой код будет на килобайт легче (магическое слово AlignChildrenProc нигде твоим кодом не цепляется)
Это главный смысл KOL-а. Реализованный на объектах у который куча всяких property

В какой это версии Delphi вдруг классы обзавелись счётчиками ссылок?

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

Ничего подобного. В Delphi 7 cтроки - со счётчиками, интерфейсы тоже, но не классы. Экземпляры class'ов надо удалять вручную.

Да-да, я тоже помню, что это только для классов, которые реализуют интерфейсы. Т.е. COM-классов.

Счётчики ссылок только в строках и динамических массивах, для которых реализовано свойство copy-on-write. Вся остальная память управляется вручную. Главное отличие классов от объектов - экземпляры классы всегда динамические, поддержка Run-Time-Type-Information (что-то вроде мета-данных). Объекты помечены как устаревшие и у них отсутствует ряд полезных для Delphi вещей, таких как свойства. Про остальное вроде бы сказали.

Вынужден согласиться
ВЫ ПРАВЫ. Два для подсматривал, не мог поверить... Никаких намеков на "барьер записи"
Бред какой-то. Теперь я полностью потерял веру в разум разработчиков от Бормана
Были структуры данных. И обогатили фишками ООП и получился OBJECT. Вот и славненько, казалось бы.

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

Ну да, чуток отличается (скажем, магическое слово override не катит, но по факту - override) от аналогичных механизмов в классах. Но вот на фига ради не очень понятных отличий городить такого монстра - понимание исчезло напрочь.
Да еще и документировал бы кто эти "отличия" по человечески....

Поддерживаю, ибо тоже не понимаю.
Раньше писал себе OBJECT и всё было хорошо.
Теперь надо писать CLASS. А вчём отличия (кроме размещения естественно) --- непонятно. Я и OBJECT мог по факту разместить в динамической памяти, через ссылку на объект.

Это обычные косметические "улучшения" языка. Object был добавлен в ТурбрПаскаль, дай бог памяти, еще в версию 4. Это 80-е годы - когда С++ еще не был настолько популярен.
С ростом популярности С++ решили в Делфях добавить более "современную" конструкцию class - под влиянием моды на С++.
Аналогичные вещи происходят и в других местах. Например, в C# были generics, а потом под влиянием моды добавили template. О контейнерах я уж и не говорю - были одни контейнеры, потом добавили другие - с той же функциональностью.
Так что не заморачивайтесь, а просто используйте то, что привычно.

Самую малость про "устаревшее" и "теперь надо"
В какой последовательности в Дельфи появлялось это - не застал и не помню.
А вот FPC начинался почти полного игнорирования объектов - типа устаревшие...
У нас даже две версии KOL-а были - родной, сделанный на объектах, и портированный, сделанный на классах для FPC (v1.93, кажется)
А вот далее уже начали в FPC включать поддержку объектов по полной программе. И авторский KOL уже начал компилироваться.

Так что, кто из них "устаревший" - дискуссионный вопрос
Как минимум, концепция "устаревшести объектов" не прошла испытание временем в FPC

+1

Они просто добивались полной обратной совместимости с делфи. Не поддержав Object этого не добиться, вот и всё.

И все равно не добились
А на результирующий код смотреть (сравнить с дельфячим) без слез невозможно

В смысле?
Помнится портировал я одну утилитку с делфи на лазарус. Собственно не портировал а пересобирал. Только контролы немного съехали, пришлось их мышкой поперетаскивать на места. Проблем небыло никаких.

Т.о. код дельфячий ничем не отличался от кода fpc'ного

Это только в Вашей голове добавили.

По мелочам, в общем-то... Но когда наступаешь, мало никогда не кажется
Предполагается бинарная совместимость в режиме -MDelphi. И она на 99% есть. А вот передача контекста во вложенных процедурах - уже не так... На асм-вставках глючит (опять же - на 1-ом проценте).
Какого хрена было вообще иной регистровый интерфейс делаешь, если ставишь задачу замены - тайна сия велика есть.
Ну есть еще какие-то страшные встроенные COM-слова в Дельфях, которые FPC не понимает в упор... Хотя давно не следил уже.