Delphi vs C++ , Часть 1

Цитата

Имеет, конечно, но, я думаю, ноги растут именно оттуда.

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

Цитата

Подозреваю, что при этом inner-объекту делается специальный вызов CoCreateInstance (с ненулевым параметром pOuter)

ВНЕ технологии COM - никакого coCreateInstance. Обычный вызов конструктора (таки да, с ненулевым параметром, ссылающийся на внешний объект).

Цитата Flex Ferrum @ 11.03.08, 13:29

Подозреваю, что при этом inner-объекту делается специальный вызов CoCreateInstance (с ненулевым параметром pOuter), и прочее.

Нет. В случае FBar := TBarImpl.Create никаких coCreateInstance. По причине полной бессмысленности: интерфейс не опубликован. Ну и по причине того, что и о самой CoCreateInstance ничего не известно. Никаких коклассов.

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

Нет. В случае FBar := TBarImpl.Create никаких coCreateInstance. По причине полной бессмысленности: интерфейс не опубликован. Ну и по причине того, что и о самой CoCreateInstance ничего не известно. Никаких коклассов.

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

Обычный вызов конструктора (таки да, с ненулевым параметром, ссылающийся на внешний объект).

Добавлено 11.03.08, 13:35
В противном случае AddRef и Release у тебя не будут корректно работать, и объект может придти в совершенно несогласованное состояние.

Цитата archimed7592 @ 11.03.08, 12:23

Не надо мне особой корректности. Сойдёт что-то вроде
var app, wb, ws:variant;
begin
app = CreateObject('Application.Excel');
wb = app.Workbooks.Add;
ws = wb.Worksheets[1];
ws.Range('B7').Value = 99;
ws.Range('A3').Value = 'abc';
end.
Подкорректируйте до работоспособности.

Возвращаясь к вялотекущим обсуждениям. Сравни с отрывком:

var
  V, A: Variant;
begin
  V := varComplexCreate;
  V.Real := 1;
  V.Imaginary := 1;
  A := V + 1;
  ShowMessage(A);
end;

Цитата

Потому что

Цитата (--Ins-- @ Сегодня, 16:24)
Все верно. Тут нужно либо самому вложить такое поведение в агрегат (не путаю термины?), либо унаследовать его от TAggregatedObject, где все это уже реализовано.

TAggregatedObject не связан с TComObject никаким боком А COM начинается именно с TComObject. Классы TInterfacedObject, TContainedObject, TAggregatedObject с COM не связаны никак, они даже в объявлении не содержат слово IUnknown, а IInterface (TAggregatedObject вообще не реализует никаких интерфейсов), чтобы подчеркнуть свою независимость от COM.

Цитата archimed7592 @ 11.03.08, 12:19

А как насчёт void foo(char *, int, char, double ***);

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

Цитата --Ins-- @ 11.03.08, 13:39

TAggregatedObject не связан с TComObject никаким боком А COM начинается именно с TComObject. Классы TInterfacedObject, TContainedObject, TAggregatedObject с COM не связаны никак, они даже в объявлении не содержат слово IUnknown, а IInterface (TAggregatedObject вообще не реализует никаких интерфейсов), чтобы подчеркнуть свою независимость от COM.

Тогда зачем, объясни мне, передавать указатель на outer-объект?

Цитата

В противном случае AddRef и Release у тебя не будут корректно работать, и объект может придти в совершенно несогласованное состояние.

Само собой А медведь живет в лесу И что с того?

Добавлено 11.03.08, 13:45

Цитата

Тогда зачем, объясни мне, передавать указатель на outer-объект?

Потому что согласно правилам языка, интерфейсы - автоматически финализируемые типы данных. Для них ведется подсчет ссылок, как и для строк. И все эти махинации нужны для того, чтобы как вы сами сказали, объект не пришел в несогласованное состояние. Все ли верно? Если да, то где тут вы видите слово COM?

Цитата Flex Ferrum @ 11.03.08, 13:34

Нет. В случае FBar := TBarImpl.Create никаких coCreateInstance. По причине полной бессмысленности: интерфейс не опубликован. Ну и по причине того, что и о самой CoCreateInstance ничего не известно. Никаких коклассов.


Цитата (--Ins-- @ Сегодня, 16:32)
Обычный вызов конструктора (таки да, с ненулевым параметром, ссылающийся на внешний объект).

Добавлено Сегодня, 16:35
В противном случае AddRef и Release у тебя не будут корректно работать, и объект может придти в совершенно несогласованное состояние.

Неа. Не придет. Все дело в том, что присвоение FBar инкрементирует счетчик реализации в TBarImpl (это интерфейс). И пока FBar не станет nil - все работает.

Цитата --Ins-- @ 11.03.08, 13:41

Само собой А медведь живет в лесу И что с того?

А почему интерфейсы вообще реализуют подсчет ссылок, идя в этом вразрез с принятой в Delphi стратегией управления памятью?

Добавлено 11.03.08, 13:48

Цитата Romkin @ 11.03.08, 13:45

Неа. Не придет. Все дело в том, что присвоение FBar инкрементирует счетчик реализации в TBarImpl (это интерфейс). И пока FBar не станет nil - все работает.

Тут не все так просто. Когда клиент берет указатель на интерфейс, он, вообще говоря, не знает - как именно этот интерфейс будет получен и от кого. С точки зрения внешнего наблюдателя, IBar является интерфейсом объекта TMy, а не вложенного в него подобъекта. А потому все изменения ссылок должны затрагивать объект-хозяин, а не вложенный в него объект.

Цитата --Ins-- @ 11.03.08, 13:08

Если язык не будет успевать с ней в ногу - он устареет и умрет. Вводить стандарт - это тормоз в развитии языка.

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

Цитата

идя в этом вразрез с принятой в Delphi стратегией управления памятью?

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

Цитата Flex Ferrum @ 11.03.08, 13:45

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

Совершенно не факт. Мне как раз понадобилась оболочка, время жизни которой контролируется мной (элемент коллекции), реализующая интерфейс, который передается наружу. А сточки зрения наблюдателя - он вообще не должен делать предположений, какому объекту принадлежит данный интерфейс!
А вот в приведенном выше примере - да, ins совершенно правильно заметил, реализация должна идти через агрегацию. Не из-за подсчета ссылок, а из-за требования обеспечения симметрии интерфейсов.

Цитата

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

Ты отраслью ошибся Не тот случай

Цитата --Ins-- @ 11.03.08, 13:55

Ты отраслью ошибся Не тот случай

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