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

Цитата KILLER @ 11.02.13, 13:23

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

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

Цитата --Ins-- @ 11.02.13, 13:10

Перепости, плиз, мне неохота искать что именно ты имеешь в виду

Так я цитировал уже. Ты ответил. Хотя скорее ушел от ответа... Я ответил тебе. И все
Кратко:
1) как мне в Delphi изменить логику работы зашитых неявных ссылок на объекты классового типа?
2) чем тебя не устраивает typedef(синоним) для нужного типа указателя? Это позволяет получить такое же поведение, как в делфи + возможность менять вид указателя

Добавлено 11.02.13, 13:32

Цитата --Ins-- @ 11.02.13, 13:29

Все четко

Костыльно и не нужно

Цитата D_KEY @ 11.02.13, 13:29

1) как мне в Delphi изменить логику работы зашитых неявных ссылок на объекты классового типа?

Никак. Если тебе нужны не ссылочные типы - используй другой тип данных, не класс. Запись, например. Класс для этого не предназначен

Цитата D_KEY @ 11.02.13, 13:29

2) чем тебя не устраивает typedef(синоним) для нужного типа указателя? Это позволяет получить такое же поведение, как в делфи + возможность менять вид указателя

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

Добавлено 11.02.13, 13:33

Цитата D_KEY @ 11.02.13, 13:29

Костыльно и не нужно

Изящно и полезно

Цитата --Ins-- @ 11.02.13, 13:29

Нет. В случае виртуальных конструкторов фабрикой выступает класс. Он, предоставляя виртуальный конструктор, задает интерфейс инстанцирования, и потомки, поддерживая этот интерфейс, включаются в эту фабрику.

Т.е. Потомок это есть Фабрика. Верно?

Цитата KILLER @ 11.02.13, 13:35

Т.е. Потомок это есть Фабрика. Верно?

Нет. Класс, задающий интерфейс виртуального конструктора - есть фабрика.

Цитата --Ins-- @ 11.02.13, 13:32

Цитата D_KEY @ 11.02.13, 13:29

1) как мне в Delphi изменить логику работы зашитых неявных ссылок на объекты классового типа?

Никак. Если тебе нужны не ссылочные типы - используй другой тип данных, не класс. Запись, например. Класс для этого не предназначен

Эм. Мне нужен класс. ОО. Виртуальные методы и пр. Просто я не хочу руками удалять объекты класса и хочу, чтобы там был подсчет ссылок. В С++ я беру std::shared_ptr<MyClass> и вперед...

Цитата

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

К typedef'ам на указатели они привыкли

Добавлено 11.02.13, 13:42
--Ins--, давай примерчик на свои встроенные фабрики, я забыл уже, что в прошлый раз было

Цитата D_KEY @ 11.02.13, 13:38

--Ins--, давай примерчик на свои встроенные фабрики, я забыл уже, что в прошлый раз было

Нет времени фантазировать... Ты про виртуальные конструкторы? Например, класс TControl - базовый класс контролов. Задает конструктор, прототип которого все контролы поддерживают, объявляет его виртуальным. Это дает мне возможность не зная тип контрола на этапе компиляции передать ссылку на метакласс контрола и создать его экземпляр. Например:

procedure Foo(A: TControlClass);
var
  B: TControl;
begin
  ...
  B := A.Create(nil);
  ...
end;

Если я вызову эту процедуру с параметром TButton - внутри будет создана кнопка, если с параметром TPanel - панель и т.д.

Это все понятно. В принципе, это и есть фабрика и в чем преимущество - не понятно.
Я имею в виду что-то в духе добавления в список и прочего делания чего-либо после констрирования для всех объектов иерархии.

Цитата D_KEY @ 11.02.13, 13:55

В принципе, это и есть фабрика и в чем преимущество - не понятно.

Непонятно в чем преимущество фабрики?

Цитата --Ins-- @ 11.02.13, 13:58

Цитата D_KEY @ 11.02.13, 13:55

В принципе, это и есть фабрика и в чем преимущество - не понятно.

Непонятно в чем преимущество фабрики?

Не понятно, в чем преимущество вашей неявной фабрики перед обычной фабрикой.

Цитата D_KEY @ 11.02.13, 14:00

Не понятно, в чем преимущество вашей неявной фабрики перед обычной фабрикой.

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

Ладно, мы опять вернулись к старым темам и не думаю, что расскажем друг другу что-то новое.
Мне сейчас больше про ссылки интересно

Цитата --Ins-- @ 11.02.13, 12:43

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

Угу.. Когда-то довелось породиться от VCL-ного класса. Создал свой подкласс, добавил еще один член-данных, перегрузил пару-тройку виртуальных методов (благо автор базового класса таковыми их сделал) и в т.ч. перегрузил метод Clear в котором чистил свой член-данных после чего редиректил вызов базовому классу.
Все бы ничего, но работало криво и нестабильно со странными падежами. Уже моск сломал что и как, а потом выяснилось (качнул сорсы компонента на торрентах, чего греха таить) что в деструкторе базового класса вызывался метод Clear - который виртуальный и который, следовательно, вызывался на моем уже разрушенном объекте.

Это ппц просто какой был. Самое главное я моск сломал как эту проблему обойти не имея доступа к коду родительского класса (легально была только либа и интерфейсная часть). Уже какие затычки только не придумывал: и глобальные флажки, и статические коллекции указателей на объекты которые "удалены" и прочую хрень.
Хорошо что потом осенило, вспомнив что имею дело с VCL, проверять в своем дочернем классе в методе Clear свойство ComponentState на предмет флажка csDestroying...

Но до сих пор меня не покидает горькое чувство несосоятельности решения по двум причинам:
1. "хорошо" что это был VCL-ный класс у которого есть ComponentState (кстати само свойство тоже на затычку похоже) которое тянется еще с самого верха иерархии.. А если б небыло его? Как тогда быть?
2. все равно вызывается метод на разрушенном объекте (по сути в метод передается невалидный this или self как там его..) который просто по условию на флажок сразу покидается.

Хорошая иллюстрация к тому, о чем мы говорили в различных инкарнациях холивара Delphi vs C++

Цитата Chow @ 11.02.13, 14:41

"хорошо" что это был VCL-ный класс у которого есть ComponentState

хм...

destructor TMyObj.Destroy;
begin
  inherited;
  // удаляем своё
end;