Множественное наследование
Модератор: Модераторы
Эхъм) Тогда куль! ..чтой-то я напутал наверно тогда)
>{$INTERFACES CORBA}
тоесть если поставить эту директиву, то компилер не будет вставлять подсчет ссылок? я правильно понял?
>{$INTERFACES CORBA}
тоесть если поставить эту директиву, то компилер не будет вставлять подсчет ссылок? я правильно понял?
- Иван Шихалев
- энтузиаст
- Сообщения: 1138
- Зарегистрирован: 15.05.2006 11:26:13
- Откуда: Екатеринбург
- Контактная информация:
Не будет. Не будет наследования от IUnknown вообще (если явно не задать).
хм, довольно странно что в fpc пошли таким путем, спец деректива для работы в норм режиме.
- Иван Шихалев
- энтузиаст
- Сообщения: 1138
- Зарегистрирован: 15.05.2006 11:26:13
- Откуда: Екатеринбург
- Контактная информация:
В FPC нормальным режимом считается delphi-совместимый.
ну дык в делфе никаких деректив не надо, пошел проверять...
- Иван Шихалев
- энтузиаст
- Сообщения: 1138
- Зарегистрирован: 15.05.2006 11:26:13
- Откуда: Екатеринбург
- Контактная информация:
Чтобы получить COM-интерфейс, наследника IUnkown — не надо.
(проверил дома)
...а TForm таки наследуеться в FPC от TComponent который реализует IUnknown .. Разве в Delphi не так?
.. и да - {$INTERFACES CORBA} афигительно работает - без нее при реализации "чистого" интерфейса чистым классом было:
Error: No matching implementation for interface method "IUnknown.QueryInterface .... blablabla"
Пасиба!
...а TForm таки наследуеться в FPC от TComponent который реализует IUnknown .. Разве в Delphi не так?
.. и да - {$INTERFACES CORBA} афигительно работает - без нее при реализации "чистого" интерфейса чистым классом было:
Error: No matching implementation for interface method "IUnknown.QueryInterface .... blablabla"
Пасиба!
да я прогнал на счет IUnknown все есть правда в Delphi он проходит как IInterface
а ссылки он не считает кроме случая если не является оберткой вокруг COM
гм, совсем старый стал, нашел где я реализую эти методы в своих классах (мало таких), но чаще использую TInterfacedObject, он самоуничтожается - удобно для временных объектов.
Код: Выделить всё
TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)
private
...
а ссылки он не считает кроме случая если не является оберткой вокруг COM
Код: Выделить всё
function TComponent.QueryInterface(const IID: TGUID; out Obj): HResult;
begin
if FVCLComObject = nil then
begin
if GetInterface(IID, Obj) then Result := S_OK
else Result := E_NOINTERFACE
end
else
Result := IVCLComObject(FVCLComObject).QueryInterface(IID, Obj);
end;
function TComponent._AddRef: Integer;
begin
if FVCLComObject = nil then
Result := -1 // -1 indicates no reference counting is taking place
else
Result := IVCLComObject(FVCLComObject)._AddRef;
end;
function TComponent._Release: Integer;
begin
if FVCLComObject = nil then
Result := -1 // -1 indicates no reference counting is taking place
else
Result := IVCLComObject(FVCLComObject)._Release;
end;
гм, совсем старый стал, нашел где я реализую эти методы в своих классах (мало таких), но чаще использую TInterfacedObject, он самоуничтожается - удобно для временных объектов.
Последний раз редактировалось sts 25.11.2010 18:13:34, всего редактировалось 1 раз.
sts писал(а):хехе, вообщето это почти цитата из старой книги по ООП, спецом для процедурников придуманная, а эквивалентна она - "Зачем тогда ООП?" (которую я на вский случай добавил), а вы на нее набросились как на руководство к действию. Повторяю - суть того поста в том - Зачем тогда ООП если все процедурами делать.
Например инкапсуляция - часть кода относится только к объекту и работает с его данными - удобно же этот код скрыть в объекте, чем выводить этот список функций наружу.
Но в случае сложного функционала уже идет разделение и используется делегирование например.
perlpunk писал(а):Например инкапсуляция - часть кода относится только к объекту и работает с его данными - удобно же этот код скрыть в объекте, чем выводить этот список функций наружу.
Но в случае сложного функционала уже идет разделение и используется делегирование например.
и? невижу как то что я писал противоречит этому
Добавлено спустя 1 минуту 56 секунд:
например как правельнее, с вашей точки зрения
Form1.Show
или
Screen.ShowForm(Form1)
- Sergei I. Gorelkin
- энтузиаст
- Сообщения: 1409
- Зарегистрирован: 24.07.2005 14:40:41
- Откуда: Зеленоград
sts писал(а):например как правельнее, с вашей точки зрения Form1.Show или Screen.ShowForm(Form1)
Никто не мешает иметь метод Form1.Show, состоящий из единственного вызова screen.showform(Self)
Sergei I. Gorelkin писал(а):sts писал(а):например как правельнее, с вашей точки зрения Form1.Show или Screen.ShowForm(Form1)
Никто не мешает иметь метод Form1.Show, состоящий из единственного вызова screen.showform(Self)
ага, так оно обычно и бывает
Добавлено спустя 4 минуты 52 секунды:
а все потому что объект лучше знает к какому сервису обратится, какие параметры (и как) задать, при этом, для сложных случаев, остается "сложный" вариант.
А при {$INTERFACES CORBA} можно в рантайме узнать, реализован ли объектом какой-либо интерфейс? Если да, то как?
- Иван Шихалев
- энтузиаст
- Сообщения: 1138
- Зарегистрирован: 15.05.2006 11:26:13
- Откуда: Екатеринбург
- Контактная информация:
Если есть доступ к объекту класса, то можно — у TObject есть метод GetInterface. Если только ссылка на интерфейс, то нельзя (если заранее в интерфейсе не организовать аналог QueryInterface).
Вот-вот, про QueryInterface и речь. Смутило отсутствие этого метода, т.к. он из IUnknown.
Но TObject.GetInterface (GetInterfaceByStr) - похоже, то, что нужно, спасибо!
Но ещё остались вопросы. Для GetInterface и GetInterfaceByStr нужен GUID, правильно? А разве при {$INTERFACES CORBA} он есть?
Но TObject.GetInterface (GetInterfaceByStr) - похоже, то, что нужно, спасибо!
Но ещё остались вопросы. Для GetInterface и GetInterfaceByStr нужен GUID, правильно? А разве при {$INTERFACES CORBA} он есть?
