Теоретический пробел в TObject.Create

Приветствую!

Возник у меня некий теоретический пробел по поводу конструктора TObject.Create.

C одной стороны, он ведет себя, как функция, возвращающая указатель на созданный экземпляр.
С другой стороны, сам Delphi считает его процедурой.
В хелпе указано, что TObject.Create выделяет память, но не инициализирует данные. Но память выделяет.
А в исходниках все тело конструктора состоит из begin/end.

Правильно ли я понимаю, что этот конструктор - что-то типа разновидности команды для препроцессора, где компилятор Delphi, встречая этот вызов, сам организовывает выделение памяти и возвращение адреса созданного экземпляра?

0

Сообщение от Beltar И как это работало? Ну т. е. в какой момент становилось понятно, что родилось, подо что выделять память, и что искать в VMT?

Я сейчас точно не вспомню, там целая идея была с "поздним связыванием".
По большому счету, компилятор на этапе сборки уже отлично знает про все виртуальные методы и их вызовы. Поэтому вызов конструктора, скорее всего, просто приводил к заполнению таблицы VMT уже собранной информацией.

Сообщение от Beltar И как оно в Си++ работает?

Да примерно так же.

0

А если конструктор по условию вызывается?

0

Сообщение от Beltar А если конструктор по условию вызывается?

Насколько я помню, тупо не работал полиморфизм (не вызывались методы потомков).

0

ну вот же вариант вызова конструктора по классу, в самом начале программы
и компилятор не знает что класть в result до вызова

0

Сообщение от krapotkin ну вот же вариант вызова конструктора по классу, в самом начале программы и компилятор не знает что класть в result до вызова

Почему не знает? Где-то же по тексту программы есть вызов этой функции уже с передачей конкретного параметра конкретного типа. Вот оттуда он и знает.

0

Э-э... Передавая классовую ссылку мы прямым текстом говорим, что за класс брать. В этом суть классовых ссылок.

А Result на этапе компиляции просто размечается, как ссылка. Это ничем не отличается от превентивного объявления указателя на еще необъявленный тип, или уточнений, что TMyClass=class в начале юнита.

0

Сообщение от northener Изначально Init это процедура для инициализации объекта давно созданного.

Изначально - это где и когда? Помню Init-ы только как конструкторы ещё в паскалевских библиотеках типа TurboVision-а.

Сообщение от northener Предполагается что она уже ранее выделена.

Вообще, пример интересный. Проблемка в том, что хотелось бы увидеть альтернативный способ предварительного выделения под экземпляр класса памяти. Если есть, милости просим, очень хочется посмотреть. Эта мысль была, когда читал. К моменту написания уже кой-чего попробовал, вроде получается. У TObject-а есть метод NewInstance - хелп утверждает, что он автоматически вызывается из конструктора.
Компилятор съел. Возможно нужны ещё какие-то телодвижения...
Похоже, что очередной фокус Копперфильда разоблачён. ))) Так что, мы, с Вашего позволения, ещё немного побудем. )))

Но это не отменяет вопроса, если есть свой вариант, было б очень интересно.

Сообщение от Beltar что мешает просто уравнять object и record, сразу давая структурам еще и наследование.

Зачем? Опять городить не нужный хлам. Есть объекты - забирайте свою инкапсуляцию, а есть структуры/записи - это чистые данные, без дополнительного прицепа. Оставьте Кесарю кесарево - не изобретайте лишних сущностей. )))

Сообщение от Beltar Наверное потому, что он видит отсутствие в выражении LValue. Хотя кодогенератор такую строку помечает, как не пустую. Не давая варнингов.

Нет. Ошибка возникала при выполнении. Скорее это потому, что переменная не nil. Кстати, нужно будет попробовать записать неё что-то с потолка. Обругается, но интересно как? ))))

Сообщение от Beltar Ну и сама по себе цепочка конструкторов по inhereted

Не, ну какие inhereted-ы? Мы не смогли стартануть Последний конструктор, до вызов предыдущих даже не дошло. Так что, да, сначала подать память, потом конструктор и всё остальное.

Добавлено через 5 минут

Сообщение от krapotkin это просто термин из C ничем он более не примечателен Record ничуть не хуже, обозначает то же самое

Совершенно верно. Дедушка Вирт, конечно классный, но записи поцупал толь у Кобола, толь у Алгола. ))))) Кобол был раньше и у него были record-ы. А Си со структурами посетили нас попозже. Так что, рекОрд за рЕкордами. ))))

Добавлено через 9 минут

Сообщение от AzAtom То есть, наличие в исходнике вот этого: DelphiВыделить код 1   TObject = class тебя не смущает, учитывая, что неявно это интерпретируется/должно интерпретироваться, как: DelphiВыделить код 1   TObject = class(TObject)

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

0

Сообщение от XpomAI Delphi 1 2 MyVar := MyType.NewInstance; MyVar.Create;

Т.е., сначала выделяем память через NewInstance, а затем еще раз, но уже из Create?
Но походу, это почти то же самое, что было приведено выше

0

Сообщение от Beltar Я по Object Pascal в редакции TP 7 лишь книжку читал во время учебы, в т. ч. про ООП, я помню, что там тоже было наследование, деление по доступу, но в общем-то всё. Возможно, что там все было реализовано без базового класса, т. е. фактически получался record, но с методами и добавлением полей и методов через наследование. Если п****, поправьте. Но я так понимаю, что в этом и есть разница м/у классами, которые большие, создаются в куче только при вызове конструктора, и доступны по ссылке и объектами, которые прям при объявлении создаются в памяти, и конструктор им нужен только для инициализации. В такой системе, как я понимаю, сделать тот же полиморфизм невозможно, т. к. все уже создано, или будет создано в стеке сразу при вызове, исходя из размеров объявленной переменой объекта.

Object Pascal тогда ещё Борланды не освоили. Это был просто паскаль (турбо или борланд).

Там было вполне полноценное ООП, object и record - две большие разницы, а полиморфизм цвёл в полный рост. Не стоит хаять добротно собранную систему. ))
По поводу классов и обжектов, тоже не стоит так примитизировать. Размер object-а ограничивался только возможностями ОС. Никто не запрещал создавать их в куче, со всеми вытекающими. А конструктор - да, был необязателен, если Вы не пользовались виртуальными методами, но зачем тогда... но это уже совсем другая история. Принципиально - всё было возможно. )))

Да! Как я мог забыть! Базовый класс определялся самим программером, как самый старший предок в иерархии. И их могло быть больше одного.

Сообщение от Beltar Процедура это функция, не возвращающая обязательно результата.

Согласитесь, если процедуру определять таким образом, то функцию можно определить, как процедуру, обязательно возвращающую результат. Нет?

Добавлено через 57 секунд

Сообщение от Beltar А если конструктор по условию вызывается?

Это как?

Добавлено через 7 минут

Сообщение от Constcat Т.е., сначала выделяем память через NewInstance, а затем еще раз, но уже из Create? Но походу, это почти то же самое, что было приведено выше

Нет. Второе прогонит код Create-а два раза (рукописный). Но при этом не будут отработаны какие-то автоматические штучки. Магия проследит. )))
В первом случае мы вызываем штатный class method TObject-а, который всё равно был бы вызван при "нормальном" вызове Create-а, а теперь, возможно будет проигнорирован Магией.

Честно сказать, я не знаю. Мне это пришло в голову и было опробовано пару часов назад, дальше этого я не пошёл. Решил потрепаться на форуме. )))

Добавлено через 14 минут

Сообщение от Beltar И как это работало? Ну т. е. в какой момент становилось понятно, что родилось, подо что выделять память, и что искать в VMT? И как оно в Си++ работает?

Например, такая конструкция:

MyVar - переменная-указатель на необходимый тип или любой тип-предок.
MyType - необходимый тип.
Второй параметр, понятное дело, конструктор. Любой доступный в MyType.
Были ещё варианты с тем, что в Си называется кастомизацией, кажется. Ещё какая-то экзотика. Я сейчас уж и не помню на вскидку.

Добавлено через 5 минут

Сообщение от Constcat выделяем память через NewInstance

Кстати, я забыл главное сказать. NewInstance - виртуальный. То есть можно подшаманить и своя система выделения памяти уже не так призрачна. ))))

Добавлено через 13 минут

Сообщение от XpomAI А почему это должно смущать? В хелпе сказано, что первая форма равносильна второй. По этому, с одной стороны, запрет на второе для TObject непротиворечив (замена/подстановка не требуется), что TObject уже определён, а любое другое имя класса - уже будет наследник. А свой базовый класс нам магия не позволяет. )))))

Извините, кусочек текста потерялся. ))))) Я хотел сказать, что с другой стороны такая "рекурсия" вполне может быть допустима, и проверить мы это не можем, так как нам не удастся осуществить такое описание TObject = class(TObject) потому, что TObject уже определён.

0

Borland Pascal стал Object Pascal в версии 5.5. Т. е. они подцепили ООП и даже версию мажорную не сменили.

Сообщение от XpomAI Согласитесь, если процедуру определять таким образом, то функцию можно определить, как процедуру, обязательно возвращающую результат.

Можно.

Это как?

Это, если конструктор находится в ветке if'а или в case, и в одном случае переменная инициализируется одним конструктором, а в др. другим. Именно это и есть полиморфизм.

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

Они уже давно с методами. Тогда в чем отличие от объектов? В том, что наследования нет? Недавно им Init подвезли какой-то. Хотя я уже давно такой метод делал в качестве начальной установки значений структурки.

0

Сообщение от XpomAI Изначально - это где и когда? Помню Init-ы только как конструкторы ещё в паскалевских библиотеках типа TurboVision-а.

Ну да. Там и в те времена они и были.

Сообщение от XpomAI Вообще, пример интересный. Проблемка в том, что хотелось бы увидеть альтернативный способ предварительного выделения под экземпляр класса памяти.

Это к хакерам.

Сообщение от XpomAI Зачем? Опять городить не нужный хлам. Есть объекты - забирайте свою инкапсуляцию, а есть структуры/записи - это чистые данные, без дополнительного прицепа. Оставьте Кесарю кесарево - не изобретайте лишних сущностей.

Поздно. Записи уже давно не чистые данные.

Сообщение от Constcat Т.е., сначала выделяем память через NewInstance, а затем еще раз, но уже из Create?

Нет. Создание нового экземпляра класса с соответствующим выделением памяти выполняется только при вызове конструктора Create от имени класса, но не от имени уже ранее созданного экземпляра класса. В последнем случае магия компилятора не включается и выполняется только то, что вы видите в коде pas-файла.
Тут кто-то говорил что не понимает зачем такое нужно. Объясню не столько необходимость, сколько возможность. В форуме часто появляются вопросы от новичков, например пишущих тесты. Вопросы типа "Тест пройден. Как мне вернуть всё в начальное состояние?". Если всю инициализацию данных выполнять в OnCreate главной формы, то самое то.

0

Вообще-то методы у записей всего-лишь способ сделать нормальным поиск процедурок подходящих для них, т. к. функционально

Абсолютно одно и то же, но в первом случае мы сразу видим, что такой метод для структурки определен, а во 2-ом нет. Для этой же цели ввели хелперы. Сама запись в виде "дрова.колоть(топором)" более удобна, чем "колоть(топором, дрова)".

Как бы дедуля Вирт не маразматничал в своем маразматичном Обероне по этому поводу.

0

Сообщение от northener Создание нового экземпляра класса с соответствующим выделением памяти выполняется только при вызове конструктора Create от имени класса, но не от имени уже ранее созданного экземпляра класса. В последнем случае магия компилятора не включается и выполняется только то, что вы видите в коде pas-файла.

Это вы точно знаете, или предполагаете?

Сообщение от Beltar Это, если конструктор находится в ветке if'а или в case, и в одном случае переменная инициализируется одним конструктором, а в др. другим. Именно это и есть полиморфизм.

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

Мой опыт показывает, что конструктор максимум должен инциализировать статические поля объекта. А все остальное лучше вынести в некую процедуру Init, или какой-нибудь Setup, никто не мешает их несколько написать, для различных условий.

Сообщение от Beltar Они уже давно с методами. Тогда в чем отличие от объектов? В том, что наследования нет? Недавно им Init подвезли какой-то.

Не понял. Ты про какие структуры? Из C++? Там это полноценные классы, отличия только в мелочах, типа видимости полей "по-умолчанию".

Добавлено через 11 минут

Сообщение от Beltar Сама запись в виде "дрова.колоть(топором)" более удобна, чем "колоть(топором, дрова)".

Ну, это смотря кому и смотря, в каких ситуациях.
Запись в виде "колоть(чем, что)" более универсальна (например, "колоть(топором, дрова)"/"колоть(шприц, задница)")))
Тем более, что в примере "дрова.колоть()" есть нелогичность в том, что у объекта "дрова" есть метод "колоть". Хотя метод "колоть" присущ, скорее дровосеку. В этом смысле конструкция, которую предложил XpomAI, более логична - "дровосек.колоть(дрова, топор)".
Грубо говоря:
MyVar:=TMyClass.Create - это что-то типа: "Эй, класс! Создай мне объект из самого себя!"
MyVarL:=New(TMyClass,Create) - "Эй, менеджер памяти! Создай мне объект, описанный классом TMyClass, и вызови его конструктор Create"
- последний вариант выглядить гораздо естественней и логичнее.

0

Сообщение от Constcat Это не полиморфизм. Это раздолбайство. Разумеется, в конструкторе можно совместить различные варианты инициализации объекта. В том же C++ этому (как характерно для C++)))))) целые статьи и теории посвящаются))) В том числе - и статьи, как бороться с геммором, когда конструктор бросает исключение)))

По поводу работы конструкторов в Delphi и Си++ была очень давно статья большая на Delphikingdom. Но если вкратце, то в Delphi конструктор ВСЕГДА в try-блоке.

Если я объявил переменную, допустим

Имею я право так сделать? Имею. Какая ветка будет вызвана в каждом случае неизвестно. В случае дельфового record такое невозможно, т. к. память под Unit будет выделена на стеке при вызове процедурки с этой переменной, в размере, необходимом для этой переменной. С классом просто, есть выделенная память под ссылку, в которую будет засунута ссылка на созданный экземпляр, который знает свой класс. Отсюда и вопрос, если в объектной модели, объекты похожи на структуры, пусть и с наследованием, то как с ними сделать подобное?

Сообщение от Constcat Тем более, что в примере "дрова.колоть()" есть нелогичность в том, что у объекта "дрова" есть метод "колоть". Хотя метод "колоть" присущ, скорее дровосеку.

С точки зрения человеческого языка вы абсолютно правы, особенно, для русского и английского, которые являются SVO-языками (Subject Verb Object), хотя в мире статистически самыми распространенными являются SOV-языки, а SVO только на 2-ом месте. И такая критика ООП тоже есть. Проблема в том, что программист живет в другой реальности, у него, как правило, есть объект, с которым надо что-то сделать. У массива чисел посчитать среднее значение например. Набор данных заполнить. И к этому объекту прилагается набор прописанных методов обработки.

Это из разряда, почему в компьютерной игре персонаж часто не может перелезть через метровый заборчик или залезть куда-то через окно. И человека, который до того с компьютерными играми, да и вообще компьютерам, дела не имел это может вогнать в ступор. Он просто не понимает того, что вроде большой мир игры прописан ограничено, и простые в реальности действия в нем могут быть в силу каких-то причин не прописаны. А с др. стороны геймдизайнеры оказываются в ситуации, что надо как-то объяснить игроку, что какое-то обычно невозможное действие конкретно здесь возможно. И в миллионе игр вертикальные поверхности, по которым можно лезть, окрашиваются какой-то одной текстурой, ящики, которые можно открыть, и платформы, на которые можно запрыгнуть, помечены зелеными маркерами.

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

Класс типа Дровосек, в принципе, тоже возможен, например, сюда можно отнести классы соединений с БД. Это хорошо работает, когда есть некоторая большая область, в которой нужно много сервисных действий и централизация. Создавать подключение к БД для каждого набора данных, очевидно, бред, пусть этим один класс занимается.

Сообщение от Constcat MyVar:=TMyClass.Create - это что-то типа: "Эй, класс! Создай мне объект из самого себя!"

Это путаница между классом и экземпляром класса. Есть описание класса, по его образу и подобию создаются экземпляры. Зачем добавлять еще какой-то метод? Даже если он есть где-то в кишках. Только потому что в реальности, имея модель автомобиля надо иметь завод, который по чертежам сделает конкретный экземпляр? Но в программировании все не так. В 90-ые были идеи сделать UI, похожий на офисный стол. Для тех, кто привык. Это не зашло. Терминология от Windows осталась (папка, документ, раб. стол, корзина,...) но не более.

0

Сообщение от Beltar Это путаница между классом и экземпляром класса. Есть описание класса, по его образу и подобию создаются экземпляры. Зачем добавлять еще какой-то метод?

Это особенность языка программирования, когда с целью компактности кода вы при создании объекта задаете важные параметры его создания. Если бы ЯП не требовал соблюдения синтаксических правил, то и таких вот изысков возможно бы не появилось, хотя классический пример пунктуации: "Казнить нельзя помиловать" говорит, что не все так просто

0

Сообщение от Beltar if CreateFlyingUnit then Unit:=TFlyingUnit.Create else Unit:=TVehicleUnit.Create

А, я теперь понял, что имелось ввиду. А я подумал, что речь идет о вызовах различных вариантов конструкторов в пределах одного класса.

Сообщение от Beltar Это путаница между классом и экземпляром класса. Есть описание класса, по его образу и подобию создаются экземпляры. Зачем добавлять еще какой-то метод?

Какая путаница? Вот именно, что по описанию класса и создается экземпляр при помощи New. Собственно, в потрохах компилятора так и происходит, о чем в и упомянули:

Сообщение от Beltar Даже если он есть где-то в кишках.

Сообщение от Beltar Только потому что в реальности, имея модель автомобиля надо иметь завод, который по чертежам сделает конкретный экземпляр? Но в программировании все не так.

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

Добавлено через 6 минут

Сообщение от Beltar И программисту, имея объект дрова, проще нажать точку и получить список того, что можно сделать с дровами. По крайней мере, что создатель дров предусмотрел.

Угу. А потом на игровых форумах обсуждения на тему: "Почему танк взорвать можно, а деревянную дверь нельзя". Ну да. Создатель в объекте "дверь" предусмотрел только два метода "открыть/закрыть"))))))))

0

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

0

Сообщение от Beltar 1) Процедура это функция, не возвращающая обязательно результата.

Сообщение от XpomAI Согласитесь, если процедуру определять таким образом, то функцию можно определить, как процедуру, обязательно возвращающую результат. Нет?

Оба два нет. Из ваших определений следует, что процедура может возвращать результат. Но и функция тоже может возвращать, а может не возвращать результат. И получается что разницы нет. А она есть.
Давать им определения лучше через забытое понятие подпрограммы. И процедура и функция это подпрограммы. Функция отличается от процедуры тем, что может быть операндом выражения, а процедура - нет.

0

Сообщение от AzAtom Итак, создание объекта заключается в том, чтобы выделить память под него. Просто сколько нужно выделять памяти знает конструктор самого класса, то есть, записано в скрытом поле. А в случае с записью это значение просто вбито в скомпилированный код в месте вызова GetMem.

И тоже не так))).
Object'у не требуется конструктор, если отсутствуют виртуальные методы.
По большому счету, конструктор был нужен исключительно ради заполнения таблиц VTM и DMT. Память для объекта выделялась стандартными методами, как и для любой переменной.
Но потом кто-то решил, что экземпляр класса нужно обязательно создавать в куче (что, как по мне - очень странное решение. Даже страннее, чем все классы порождать от TObject) и совместить (теперь уже ставшим обязательным) выделение памяти с конструктором.

Добавлено через 1 минуту

Сообщение от Rayvenor Давать им определения лучше через забытое понятие подпрограммы. И процедура и функция это подпрограммы. Функция отличается от процедуры тем, что может быть операндом выражения, а процедура - нет.

Методы. Мне нравится. Хорошее общее определение)))

0

Меня до сих пор трясет от того, что происходит в програмке на Си, если пропустить амперсанд в каком-нибудь printf.

Сообщение от Constcat Вот именно, что по описанию класса и создается экземпляр при помощи New

Представим, что класс уже имеет завод по выпуску объектов.

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

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

Сообщение от Rayvenor Оба два нет. Из ваших определений следует, что процедура может возвращать результат. Но и функция тоже может возвращать, а может не возвращать результат. И получается что разницы нет. А она есть. Давать им определения лучше через забытое понятие подпрограммы. И процедура и функция это подпрограммы. Функция отличается от процедуры тем, что может быть операндом выражения, а процедура - нет.

Функция, не возвращающая значение в Си все равно называется функцией. Понятно, что термин этот пришел из математики, хотя в чисто математическом смысле функция в программировании должна быть чистой, т. е. не вносить никаких изменений вне себя, кроме возврата результата. procedure же - чисто паскалевский термин. Может алголовский, но мне лень проверять.

0