Delphi vs C++ vs C#
, ну и Java немножко, где-то ближе к старшему байту номеров страниц
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [216.73.216.156] |
|
|
Правила раздела:
| Страницы: (495) « Первая ... 210 211 [212] 213 214 ... 494 495 ( Перейти к последнему сообщению ) |
Delphi vs C++ vs C#
, ну и Java немножко, где-то ближе к старшему байту номеров страниц
|
Сообщ.
#3166
,
|
|
|
|
Цитата Romkin @ Конструктор в Delphi - инициализатор, и ничего никому не обязан. Нет ситуации в Delphi, что часть объекта сконструирована, а часть - нет. Еще раз: объект - единая сущность, конструируется она одним вызовом функции, разом, как и должно. Кстати, инициализация не размазывается, она наоборот, инкапсулируется в нужных местах. Порядок создания объекта четко определен, вот только не последовательностью предков, а шаблонным методом, единым для любого объекта. Ты не понимаешь. Смотри. Возможна такая последовательность?: 1. Хотим создать новый объект 2. Под объект выделилась память 3. Объект проинициализировался системой 4. Позвался конструктор финального объекта из метакласса 5. Этот конструктор позвал конструктор базового класса 6. Базовый класс позвал виртуальный метод, переопределённый в финальном классе 7. Виртуальный метод финального класса проинициализировал должным образом нужные поля 8. Продолжил работать конструктор финального класса (вот здесь и возникает ситуация, что часть объекта уже проинициализирована в обход конструктора). Если да, то с учётом опциональности шагов 6 и 7 кастомный конструктор финального класса должен учитывать (делать дополнительные приседания) на тот случай, если часть полей уже кто-то проинитил (недефолтно). |
|
Сообщ.
#3167
,
|
|
|
|
Хехе. Все просто: на входе в конструктор метакласс гарантирует, что объект в валидном состоянии. Если это состояние отлично от нулевого - есть возможность указать нужное, перекрыв метод кокласса. Это большая редкость, по всей библиотеке и десятка методов не наберется (не надо забывать о наличии кокласса, у которого есть свои данные и методы). Дальше в дело вступает конструктор, задача которого - провести нужную инициализацию. |
|
Сообщ.
#3168
,
|
|
|
|
Цитата Romkin @ Цитата D_KEY @ Питон лучше простотой и мощностью, гибкой и развитой системой типов, сборкой мусора. Java - как неплохой язык со статической типизацией и мощными фреймворками для одноименной платформы. Delphi тоже простой язык, может и посложнее Питона, но зато и побыстрее. Если нужно побыстрее, значит, скорее всего, понадобится С или С++ Питон универсален(от железок до веб-разработки), в отличие от. Кроме того питон мощнее С++, в отличие от Delphi. Цитата Мне-то как раз не нравится. Для прикладных задач лучше, когда она есть. Цитата Java - да, неплохой язык, но там вроде бы все методы виртуальные. А объекты - ссылки. Как тебя это не бесит? ![]() Нет, там не все методы виртуальные. Объекты ссылки - и слава богу(в питоне тоже, кстати). Плохо, что там тоже примитивные типы не ссылки, а значения, что печально. А ссылки мне нравятся, я уже говорил. Мне не нравится, когда в языке есть разделение на неявно-ссылочные/обычные типы. Цитата Цитата D_KEY @ Ну так приведи такой пример, может получится. Потомок не знает, что и как делает конструктор базового класса. Вернее "что" - знает. Создает объект. Я для Флекса отрывок привел из TInterfacedObject. В нем конструктора вообще нет, зато есть кастомная инициализация, модифицирован метод метакласса, NewInstance. Этот класс является примером того, как реализация влезает в ОО - декомпозицию твоей системы. Наследовать от какого-то класса, который не имеет никакого отношения к предметной области... И только ради того, чтобы можно было указывать интерфейсы и обрести подсчет ссылок. Жуть. |
|
Сообщ.
#3169
,
|
|
|
|
Цитата Flex Ferrum @ Если да, то с учётом опциональности шагов 6 и 7 кастомный конструктор финального класса должен учитывать (делать дополнительные приседания) на тот случай, если часть полей уже кто-то проинитил (недефолтно). Что значит "с учетом опциональности"? Конструктор базового класса вызывается из конструктора моего - значит, об этом факте я осведомлен. О том факте, что конструктор базового класса вызывает виртуальный метод, который я могу перекрыть, я так же осведомлен, по меньшей мере из документации. Шаблонные методы принято описывать, как и виртуальные, в том числе когда они вызываются. В С++ какая документация для виртуального метода? Что, в каких случаях он вызывается, никто не пишет? |
|
Сообщ.
#3170
,
|
|
|
|
Цитата Romkin @ Конструктор базового класса вызывается из конструктора моего - значит, об этом факте я осведомлен. О том факте, что конструктор базового класса вызывает виртуальный метод, который я могу перекрыть, я так же осведомлен, по меньшей мере из документации. Дело в том, что реализация базового класса может и не позвать виртуальный метод. Она может его вызывать в зависимости от каких-либо условий. Может быть такое? |
|
Сообщ.
#3171
,
|
|
|
|
Romkin, если рассматривать конструкторы, как методы объектов, то ты все правильно говоришь...
Но не ясно, почему конструктор должен быть методом объекта и почему в таком случае нет именно конструктора. То есть, если бы были конструкторы плюс отдельный метод уже созданного объекта(который бы вызывался после создания автоматически), то вопросов бы не было, он мог бы быть полиморфным и т.д. и т.п. Вам же навязали просто "обнуление"... |
|
Сообщ.
#3172
,
|
|
|
|
Цитата Flex Ferrum @ Дело в том, что реализация базового класса может и не позвать виртуальный метод. Она может его вызывать в зависимости от каких-либо условий. Может быть такое? Может. А что, в С++ вызов виртуалного метода предка из виртуального метода потомка тоже всегда автоматом идет первым? |
|
Сообщ.
#3173
,
|
|
|
|
Romkin, ты бы лучше обосновал, с какой стати конструирование объекта является методом этого же самого несконструированного объекта?
|
|
Сообщ.
#3174
,
|
|
|
|
Цитата D_KEY @ Romkin, если рассматривать конструкторы, как методы объектов, то ты все правильно говоришь... Но не ясно, почему конструктор должен быть методом объекта и почему в таком случае нет именно конструктора. То есть, если бы были конструкторы плюс отдельный метод уже созданного объекта(который бы вызывался после создания автоматически), то вопросов бы не было, он мог бы быть полиморфным и т.д. и т.п. Вам же навязали просто "обнуление"... Опять... Да, в Delphi конструктор физически метод объекта, а собственно код конструирования объекта определен раз и навсегда. Обнуление-то можно отрубить, хоть и трудно. Но никто не заморачивается, оно идет мгновенно практически и это удобно. Просто собственно конструктор в Delphi не различается от класса к классу, он использует информацию метакласса для создания объекта. То есть разница в конструировании разных объектов сведена к разнице в данных метакласса. |
|
Сообщ.
#3175
,
|
|
|
|
Цитата Romkin @ Может. А что, в С++ вызов виртуалного метода предка из виртуального метода потомка тоже всегда автоматом идет первым? Нет. Не обязательно. Но ведь может? |
|
Сообщ.
#3176
,
|
|
|
|
Цитата Romkin @ То есть разница в конструировании разных объектов сведена к разнице в данных метакласса. Но это не так. Что делать при конструировании может определить только программист. Ну да ладно, по десятому кругу идем. Не любите вы, когда все просто и однозначно |
|
Сообщ.
#3177
,
|
|
|
|
Цитата D_KEY @ Romkin, ты бы лучше обосновал, с какой стати конструирование объекта является методом этого же самого несконструированного объекта? Собственно конструирование - метод метакласса. Инициализация - метод собственно объекта. Метод метакласса создает объект, т.е. выделяет память, инициализирует по-умолчанию. При этом практически на предков наплевать. А потом берет этот объект и вызывает его конструктор, как метод этого объекта, для инициализации. Добавлено Цитата Flex Ferrum @ Цитата (Romkin @ Сегодня, 17:16) Может. А что, в С++ вызов виртуалного метода предка из виртуального метода потомка тоже всегда автоматом идет первым? Нет. Не обязательно. Но ведь может? Вот. Точно та же ситуация, что и с обычным методом. Тоже забыл - и влетел. Или перекрыл виртуальный метод - а его метод предка вызвал тогда, когда ты не рассчитываешь. Между тем магия компилятора в Delphi четко определяет последовательность конструирования объекта, раз и навсегда. Так в чем разница? Добавлено D_KEY, Flex Ferrum. Вот ответтьте еще на вопрос: вызвался конструктор объекта в С++, так на что же this указывает, если вы считаете, что объект еще не сконструирован, пока все конструкторы не вызвались? |
|
Сообщ.
#3178
,
|
|
|
|
Цитата Romkin @ D_KEY, Flex Ferrum. Вот ответтьте еще на вопрос: вызвался конструктор объекта в С++, так на что же this указывает, если вы считаете, что объект еще не сконструирован, пока все конструкторы не вызвались? this указывает на конструируемый в данный момент объект. |
|
Сообщ.
#3179
,
|
|
|
|
Цитата Romkin @ D_KEY, Flex Ferrum. Вот ответтьте еще на вопрос: вызвался конструктор объекта в С++, так на что же this указывает, если вы считаете, что объект еще не сконструирован, пока все конструкторы не вызвались? Логически не сконструирован. this указывает на конструируемый объект. Как-то так Добавлено А вообще дискуссия на тему конструкторов уже осточертела |
|
Сообщ.
#3180
,
|
|
|
|
Цитата Flex Ferrum @ this указывает на конструируемый в данный момент объект. Ну вот я и говорил, что в С++ объекты - сборка из предков, которая делает вид что она единое целое А в Delphi такая логика оставлена только для метаклассов, у которых действительно и конструкторы невиртуальные, и вызываются они в строгой последовательности от предка к потомку и все остальное... А потом уже есть метаклассы, с помощью которых и создаются экземпляры объектов. Последовательность, в которой строится любой объект, жестко задана. И объект собирается метаклассом в этой последовательности, но уже как единое целое. При этом проблемы, о которых вы упоминаете, что надо знать что когда вызывается, на самом деле те же, что и всегда: если ты перекрываешь виртуальный метод, ты должен знать, когда его может вызвать предок, и не забыть вызвать метод предка. Причем еще надо учесть, что в Delphi можно вызвать метод только непосредственного предка, через inherited. Чтобы позвать дедушку - надо попотеть. Добавлено Цитата D_KEY @ А вообще дискуссия на тему конструкторов уже осточертела Угу. Я уже выяснил все что нужно, и объяснил все что можно... |