Как интерфейсы устроены "под капотом"?

Вопросы программирования на Free Pascal, использования компилятора и утилит.

Модератор: Модераторы

Re: Как интерфейсы устроены "под капотом"?

Сообщение Cheb » 09.03.2019 16:27:08

, какого ада в отладке ты избежал.

Немного мимо, т.к. я не пользуюсь отладчиками. Только debug writes и матрёшечная система try с накоплением сообщения об ошибке.

когда сериализуется объект а его интерфейс содержит метод сериализации. Но вот сериализация самого интерфейса...

А по другому просто не бывает. Я шёл путём "наследовать все интерфейсы от базового, у которого есть метод "получить инстанс объекта".
Т.е. задача была решаема таким путём, когда ты сам создаёшь интерфейсы под сериализацию (в общем случае - нерешаема, т.к. за интерфейсом в общем случае может скрываться объект ОП, объект ЦПП или любая другая неведома зверушка).

Буханку хлеба можно превратить в троллейбус.
Но зачем?

В моём случае интерфейсы могли пригодиться для гуя и глобального ИИ, давая свободу от дерева наследования. Но впилить их смериализацию в мою перзистентную систему - это *такой* геморрой. Проще извратиться с наследованием от общего абстрактного предка и в уже в него него периодически пихать новые фичи, даже если их будет использовать 5% потомков. VMT потерпит, рожа не треснет.

А для физики и прочих оптимизированных вещей интерфейсы неоправданно толстые. Обёртки, подсчёт ссылок... Не, нуегона.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 994
Зарегистрирован: 06.06.2005 15:54:34

Re: Как интерфейсы устроены "под капотом"?

Сообщение Лекс Айрин » 09.03.2019 18:05:36

Вот так сюрприз... Там где фишка нужна она слишком толстая :(
Я так понимаю, интерфейсы изначально это способ залезть в недра операционки. Ну и добавить свой функционал при необходимости.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: Как интерфейсы устроены "под капотом"?

Сообщение stanilar » 09.03.2019 18:15:15

Cheb писал(а):Немного мимо

Прямо в глаз! Это чтоб понять, что интерфейс указывает не на тот объект, который должен быть, нужно залогировать состояние всех переменных в конкретном месте программы, за все время работы. А потом еще и анализировать этот лог. Вот так выглядит дно программистского ада.

Добавлено спустя 12 минут 46 секунд:
Cheb
Все равно не понимаю. В моем понимании интерфейсы это объявление/декларация вызовов(ну есть еще всякие добавки, в виде геттеров/сеттеров, оформленные под переменную/свойства интерфейса. Вроде как есть либо в последних дельфях, либо в явах. Но это все для тех, кто не умеет/нет возможности пользоваться классами). Почти как объявление класса. Грубо говоря, из var object = TObject.create(); ты собираешься сериализовать не сам объект object, а объявление TObject? Ну так сериализованный TObject это просто текст программы, а фабрика для него - компилятор языка, на котором написан текст программы.
stanilar
постоялец
 
Сообщения: 289
Зарегистрирован: 09.03.2010 19:09:02

Re: Как интерфейсы устроены "под капотом"?

Сообщение Cheb » 10.03.2019 03:49:08

Прямо в глаз! Это чтоб понять,

Отказываюсь разводить флуд.

Но это все для тех, кто не умеет/нет возможности пользоваться классами).

Интерфейс позволяет завести параллельные сущности, независимые от дерева наследования классов. Можно в одну кучу собирать (и одной переменной типа интерфейс присваивать) классы, не имеющие общего предка с нужными методами или вообще ктулхуфтагны, созданные на другом ЯП.

З.Ы. И это бесценно когда вам надо поженить *чужие* классы из сторонней библиотеки, методы в которые вы добавлять не можете, поскольку библиотеку периодически приходится обновлять. Утрируя, надо сделать совместимыми по присваиванию TStringList из FCL и THTTPRequest из synapse.
Классический подход - создавать собственные форки обеих библиотек, делать этим классам общего предка, мучиться с поддержкой этих своих форков, повторяя всю работу при каждом обновлении или оставаясь с устаревшими библиотеками.
Интерфейсы - просто наследуешь от этих классов, вставляя обоим потомкам один интерфейс. Просто.

Там где фишка нужна она слишком толстая

Не то, чтобы такая уж толстая, но у меня пунктик по поводу супер-эффективности физики и вообще логики.
Кому-то такая стоимость может иметь вес пера, всё относительно.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 994
Зарегистрирован: 06.06.2005 15:54:34

Re: Как интерфейсы устроены "под капотом"?

Сообщение скалогрыз » 11.03.2019 08:52:49

Cheb писал(а):..подсчёт ссылок...

не считай ссылки, используя CORBA интерфейсы. (правда и QueryInterface придёться уже свой написать... но тут же и место для оптимизации. Вроде место поиска по ГУИ использовать какой-нить DWORD или ansichar[4])

Cheb писал(а):и прочих оптимизированных вещей интерфейсы неоправданно толстые

на тот же DirectX API вроде бы не кто не жаловался, дескать "он тормозной, потому что на интерфейсах", не?

Cheb писал(а):не имеющие общего предка с нужными методами или вообще ктулхуфтагны, созданные на другом ЯП

а в данном вопросе, где нужна интеграция в спроизвольным ЯП, твоя альтернатива это Си-совместимые функции:
*Си-совместимые, подразумевается, что ты будешь исползовать только те типы, которые не требуют pascal RTL. например исопльзовать pchar вместо строк
Код: Выделить всё
function InitObject(data: Pointer;  ...);
function FreeObject(data: Pointer;  ...);
function DoSomething(data: Pointer; ...);

естественно набор таких методов, лучше объеденить в структуры:
Код: Выделить всё
  TSomeObj = record
   InitObject : function (data: Pointer;  ...);
   FreeObject : function (data: Pointer;  ...);
   DoSomething : function (data: Pointer; ...);
  end;

и внезапно получаем тот же самый интерфейс, только с бОльшим количеством писанниы.
(такой подход используется в gtk, если я не ошибаюсь... но в zlib-е точно!)

Cheb писал(а):Интерфейс позволяет завести параллельные сущности, независимые от дерева наследования классов.

Ничего лучше для обхода "строгой йерархий" классов не придумали.

Хотя нет, в рефлексивный языках (где RTTI царь и бог), метод можно вызывать по имени (н.р. Objective-C, javascript)
Очевидно, что такое же можно уже реализовать в паскале. Но будет неудобно... либо очень дорого - как это было сделано с variants и Dispatch Interface.
(если я не ошибаюсь RTTI invoke, есть только в trunk-е , а официальном релизе его ещё нет)
но если хочется, то наверное libffi в руки, чтобы было сразу кроссплатформенным.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Как интерфейсы устроены "под капотом"?

Сообщение sts » 11.03.2019 09:17:09

скалогрыз писал(а):на тот же DirectX API вроде бы не кто не жаловался, дескать "он тормозной, потому что на интерфейсах", не?

Постоянно жаловались, даже я во времена 5-ой версии, только к 10-версии более мене решили проблему, кардинально поменяв архитектуру. Если отследить эволюцию кода то станет заметно что все развитие сводилось к минимизации вызовов методов интерфейсов и количества экземпляров. Помнится доже интел какието оптимизации делала в процессорах чтоб максимально снизить оверхед микрософтовских интерфейсов (хвасталась в анонсах), потом конечно проблема нивелировалась, процессоры стали ну очень быстрые (к 2010)

Добавлено спустя 3 минуты 48 секунд:
Сейчас вернулись к этой проблеме (производительности взаимодействия между прикладным слоем и железом), Vulcan придумали.
sts
постоялец
 
Сообщения: 406
Зарегистрирован: 04.04.2008 12:15:44
Откуда: Тольятти

Re: Как интерфейсы устроены "под капотом"?

Сообщение Лекс Айрин » 11.03.2019 10:02:04

скалогрыз,ну да... Только вот почему-то придумали opengl/xl. Конечно,для этого была ещё куча причин, но сам факт...
Директ икс был настолько тормозной, что первые игрушки продолжали писать под досом. И только когда появилась 95-98 винда потихоньку стали его использовать.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: Как интерфейсы устроены "под капотом"?

Сообщение Дож » 11.03.2019 16:41:00

Интерфейс позволяет завести параллельные сущности, независимые от дерева наследования классов. Можно в одну кучу собирать (и одной переменной типа интерфейс присваивать) классы, не имеющие общего предка с нужными методами или вообще ктулхуфтагны, созданные на другом ЯП.


Разовью предложение скалогрыза.

Объявление интерфейса:
Код: Выделить всё
type
PMyInterfaceVMT = ^TMyInterfaceVMT;
TMyInterfaceVMT = record
   DoSomething: procedure(Instance: Pointer);
   DoSomething2: procedure(Instance: Pointer);
end;

IMyInterface = record
private
  Instance: Pointer;
  VMT: PMyInterfaceVMT;
public
  procedure Setup(I: Pointer; V: PMyInterfaceVMT);
  procedure DoSomething; inline;
  procedure DoSomething2; inline;
end;

procedure IMyInterface.Setup(I: Pointer; V: PMyInterfaceVMT);
begin
  Instance := I;
  VMT := V;
end;

procedure IMyInterface.DoSomething; inline;
begin
  VMT^.DoSomething(Instance);
end;

procedure IMyInterface.DoSomething2; inline;
begin
  VMT^.DoSomething2(Instance);
end;


Специализация интерфейса для заданного класса TSomeObject:
Код: Выделить всё
procedure SomeObject_DoSomething(Instance: Pointer);
begin
  Writeln(TSomeObject(Instance).ClassName);
end;

procedure SomeObject_DoSomething2(Instance: Pointer);
begin
  // ...
end;

const
  MyInterfaceForSomeObject: TMyInterfaceVMT = (
     DoSomething: @SomeObject_DoSomething;
     DoSomething2: @SomeObject_DoSomething2
   );

function AsMyInterface(SomeObject: TSomeObject): IMyInterface; inline;
begin
  Result.Setup(SomeObject, @MyInterfaceForSomeObject);
end;


Использование:
Код: Выделить всё
  MyInterface := AsMyInterface(SomeObject);
  MyInterface.DoSomething;


Никаких подсчётов ссылок, выделений памяти в куче, RTTI и прочего, только виртуальные вызовы. Из минусов только, что типы не проверяются при компиляции (в местах TSomeObject(Instance) и Result.Setup(SomeObject, @MyInterfaceForSomeObject)).

на тот же DirectX API вроде бы не кто не жаловался, дескать "он тормозной, потому что на интерфейсах", не?

Здрасьте, это одна из топовых жалоб на директикс :)

Ничего лучше для обхода "строгой йерархий" классов не придумали.

Придумали, называется множественное наследование и успешно применяется программистами на питоне и C++ :)
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

Re: Как интерфейсы устроены "под капотом"?

Сообщение stanilar » 11.03.2019 22:23:21

Дож писал(а):Использование:


И вот тут до меня дошло, что хочет Cheb от сериализации интерфейсов.
Или почему скалогрыз заговорил про variants и Dispatch Interface.
stanilar
постоялец
 
Сообщения: 289
Зарегистрирован: 09.03.2010 19:09:02

Re: Как интерфейсы устроены "под капотом"?

Сообщение скалогрыз » 11.03.2019 22:57:52

sts писал(а):Если отследить эволюцию кода то станет заметно что все развитие сводилось к минимизации вызовов методов интерфейсов и количества экземпляров.

так в OpenGL тоже самое.
Помню DirectX критиковали во всяких статьях, что он плох, потому что там Immediate Mode нет (glBegin / glEnd)
А в итоге оказывается, что Immediate Mode это пережиток прошлого, и страшное зло, и таких непотребств в продакшен коде быть не должно! (привет, ZenGL!)

sts писал(а):Vulcan придумали.

Придумали не то чтобы Вулкан, а скорее (не)додумались до нормального графического АПИ. Вместо этого дали больше прямого доступа к железу.
А потому имеем, DirectX12 (замена DirectX11 и ниже), и Вулакн (замена OpenGL и OpenGLES), и Метал (замена OpenGL и OpenGLES для Apple).
Это общая тенденция. И да, DirectX 12 на интерфейсах.

Лекс Айрин писал(а):скалогрыз,ну да... Только вот почему-то придумали opengl/xl. Конечно,для этого была ещё куча причин, но сам факт...
Директ икс был настолько тормозной, что первые игрушки продолжали писать под досом. И только когда появилась 95-98 винда потихоньку стали его использовать.

OpenGL придумали в 92м году. Дх "придумали" в 95м (т.к. он входил в 95-ую винду)
Игры после выхода 95ой винды продолжали писать под ДОС:
а) по инерции (и потом да и не все пользователи перешли на 95ую). (Сейчас мы наблюдаем тоже самое, когда всё ещё выходят игры с поддержкой 9x или WinXP)
б) доступность ресурсов. Под ДОС-ом ты получаешь - ВСЁ железо в которе умеешь, а в винде всё-равно нужно делиться ресурсами.
Т.е. говорить можно не о тормознутости Дх, а уже о тормознутости Винды.

OpenGLES придумали для мобильных систем (например, чтобы не ложиться под M$, и исползовать наработки от оснвного OpenGL)
Под какую-нить Xbox писать всё-равно придёться на DirectX-е.

Дож писал(а):Здрасьте, это одна из топовых жалоб на директикс :)

я понимаю, что жаловались когда-то там давно, дескать Api в DirectX 3 или DirectX 5 убогий, и с ним приходится воевать.
Но непосредственного отношения к тому что используются COM интерфейсы это отношения не имеет.

Дож писал(а):Придумали, называется множественное наследование и успешно применяется программистами на питоне и C++ :)

по-моему, проблемы множественного наследования, на классах с интерфейсами не проявляются.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Как интерфейсы устроены "под капотом"?

Сообщение Mirage » 11.03.2019 23:45:49

В DirectX интерфейсы не особо тормозили. Там работы с ними не так много по сравнению со всем остальным.
Так что использовать их можно, но осторожно, чтоб где не надо всякие неявные стекфреймы не возникали на ровном месте. Впрочем, они возникают не только из-за интерфейсов, но и из-за дин. массивов и строк.

скалогрыз писал(а):Помню DirectX критиковали во всяких статьях, что он плох, потому что там Immediate Mode нет (glBegin / glEnd)


DirectX сам один большой immediate mode. В свое время там были два режима: retained mode и immediate mode. Выжил только последний. :)
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Как интерфейсы устроены "под капотом"?

Сообщение Лекс Айрин » 12.03.2019 01:20:44

скалогрыз, так директ икс и был задуман как возможность прямого, в меру возможностей, доступа к аппаратуре, так как обычными средствами было слишком тяжко пользоваться. Соответственно, только игры типа тетриса/сапёра/косынки и сделаешь. Даже 98 была недоосью поверх досовского недоядра. Так что этот набор хаков был необходим.
Под 98 Винду новых игр уже нет. Даже под хр не очень найдешь. Предполагается, что для новых игр нужно новое оборудование. Печатные машинки не требуют апгрейда лет по 20. Вообще, прикольно получилось, что недостатки оси компенсируются аппаратно. У меня, кстати, иногда директ икс глючил и не цеплялся к оборудованию, обычно к звуковому. Приходилось часть возможностей отключать.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: Как интерфейсы устроены "под капотом"?

Сообщение скалогрыз » 12.03.2019 01:35:09

Лекс Айрин писал(а):так директ икс и был задуман как возможность прямого, в меру возможностей, доступа к аппаратуре

ну значит мы сошлись на том мнении, что интерфейсы можно использовать для низкоуровненвых целей, и тормозов это не добавит?!
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Как интерфейсы устроены "под капотом"?

Сообщение Лекс Айрин » 12.03.2019 02:23:01

скалогрыз, а это уже зависит от реализации самих интерфейсов. Ну и от аппаратной поддержки.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: Как интерфейсы устроены "под капотом"?

Сообщение stanilar » 12.03.2019 19:04:27

Лекс Айрин писал(а):это уже зависит от реализации самих интерфейсов.


Чем реализация интерфейсов отличается от реализации импорта процедур из библиотек? Особенно, если говорить об интерфейсе синглтона.
stanilar
постоялец
 
Сообщения: 289
Зарегистрирован: 09.03.2010 19:09:02

Пред.След.

Вернуться в Free Pascal Compiler

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 29

Рейтинг@Mail.ru