Здравствуйте, hattab, Вы писали:

H>Повышение производительности за счет инлайнинга операций подсчета ссылок, это сродни полировке заклепок на танке, в надежде улучшить его аэродинамику.

Мда... Мозги у вас зашорены основательно. Ну подумайте сами — имеет ли смысл не инлайнить функции, расходы на исполнение которой сопоставимо с расходами на её вызов? Ведь в случае инлайна прирост производительности этого фрагмента будет очень серьёзным...

Здравствуйте, gandjustas, Вы писали:

H>>>>>>COM-интерфейс:
H>>>>>>

H>>>>>>ICOMInterface = Interface(IUnknown)
H>>>>>>[...]

H>>>>>> Procedure GetAppName : WideString; StdCall;

H>>>>>>End;
H>>>>>>

H>>>>>>Не COM-интерфейс:
H>>>>>>

H>>>>>>INonCOMInterface = Interface(IUnknown)
H>>>>>>[...]

H>>>>>> Procedure GetAppName : AnsiString;
H>>>>>> Procedure ClearList(AList : TList);

H>>>>>>End;
H>>>>>>

G>>>>>А то что они наследуют IUnknown ничего не значит уже?

H>>>>Конечно не значит. Учи матчасть.
G>>>А что тогда занчит?

H>>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы.
G>Семантика — поведение в данном случае. Если объект выглядит как COM и ведет себя как COM, почему он не является COM?

Да он (INonCOMInterface) даже не выглядит, как COM . Соглашение о вызовах в COM какое? А тут какое? Типы допустимые в COM, какие? А тут? Общаться с тобой все веселее и веселее...

Здравствуйте, koandrew, Вы писали:

H>>Повышение производительности за счет инлайнинга операций подсчета ссылок, это сродни полировке заклепок на танке, в надежде улучшить его аэродинамику.

K>Мда... Мозги у вас зашорены основательно. Ну подумайте сами — имеет ли смысл не инлайнить функции, расходы на исполнение которой сопоставимо с расходами на её вызов? Ведь в случае инлайна прирост производительности этого фрагмента будет очень серьёзным...

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

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, Mamut, Вы писали:

kuj>>>>>Не на столько разные, чтоб заморачиваться.
M>>>>Очень разные. Erlang — не логический язык программирования.

kuj>>>Мамут как всегда на высоте... взял и обосрал Erlang. Мол, нелогичный он какой-то...


M>>Ты бы это... Взял бы и посмотрел на Эрланг, что ли. Prolog и Erlang — два абсолютно разных языка.

kuj>Эх, Мамут-Мамут, сам-то читал? Эрланг и Пролог — функциональные языки. Эрланг базируется на идентичном Прологу синтаксисе. Да, в Эрланг много всего того, чего нет в Прологе, но это не значит, что он хуже для преподавания. Скорее наоборот.


То, что они оба функциональные и то, что синтаксис Эрланга похож на паскалевский, не значит, что они взаимозаменяемы. Пролог ты Эрлангом не заменишь.


kuj>Вообще RTFM Мамут, RTFM.


Сам их читай. Это не моя цитата:

Вместо Prolog — Erlang

Здравствуйте, gandjustas, Вы писали:

G>>>>>Новое слово в ООП — приведение типов, когда не заешь к чему приводить....
H>>>>Именно так. Именно поэтому интерфейсы. Начинай расширять сознание уже.
G>>>
G>>>Ржунимагу, уж простите.

H>>Поржал? Теперь подумай: на момент проектирования класса/объекта ты не будешь знать к чему придется приводить твой объект. А может DOOM, именно об этой статике в голове говорил...
G>Да, буду. Объект всегда приводится к одному их базовых классах или к одному их реализуемых интерфейсов. Другого просто не может быть.

Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.

Здравствуйте, hattab, Вы писали:

H>>>Повышение производительности за счет инлайнинга операций подсчета ссылок, это сродни полировке заклепок на танке, в надежде улучшить его аэродинамику.

K>>Мда... Мозги у вас зашорены основательно. Ну подумайте сами — имеет ли смысл не инлайнить функции, расходы на исполнение которой сопоставимо с расходами на её вызов? Ведь в случае инлайна прирост производительности этого фрагмента будет очень серьёзным...

H>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах. А теперь прикинь, как нечасто вызываются эти функции.

Хохо, и это говорит человек, который сравнивал Delphi и .NET бенчмарком со 100 млн. итераций. Браво-браво... Называется, за что боролись, на то и напоролись.

Здравствуйте, hattab, Вы писали:

G>>>>>>Новое слово в ООП — приведение типов, когда не заешь к чему приводить....
H>>>>>Именно так. Именно поэтому интерфейсы. Начинай расширять сознание уже.
G>>>>
G>>>>Ржунимагу, уж простите.

H>>>Поржал? Теперь подумай: на момент проектирования класса/объекта ты не будешь знать к чему придется приводить твой объект. А может DOOM, именно об этой статике в голове говорил...
G>>Да, буду. Объект всегда приводится к одному их базовых классах или к одному их реализуемых интерфейсов. Другого просто не может быть.

H>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.




/из под стола: он все еще не понимает...

Здравствуйте, kuj, Вы писали:

H>>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы.

kuj>"In programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM). The published COM specification mandates that COM objects must minimally implement this interface. Furthermore, every other COM interface must be derived from IUnknown."

kuj>"IInterface

kuj>Basic interface for all COM based interfaces
kuj>Declaration

kuj>Source position: objpash.inc line 196

kuj>type IInterface = IUnknown;
kuj>Description

kuj>IInterface is the basic interface from which all COM style interfaces descend."


kuj>hattab, хватит уже расширять свое сознание.

ignore off

Я и сказал, что IInterface это идентичный IUnknown тип. Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать

ignore on

H>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.

Для таких случаев делается wrapper-объект, который содержит старый объект в виде приватной переменной. И?

Здравствуйте, hattab, Вы писали:

hattab, ты утопил своей глупостью.

Повторяй как мантру:

IUnknown — COM-интерфейс
Любой интерфейс-наследник IUnknown — COM-интерфейс
Любой интерфейс-наследник COM-интерфейса — COM-интерфейс

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, kuj, Вы писали:

H>>>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы.

kuj>>"In programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM). The published COM specification mandates that COM objects must minimally implement this interface. Furthermore, every other COM interface must be derived from IUnknown."

kuj>>"IInterface

kuj>>Basic interface for all COM based interfaces
kuj>>Declaration

kuj>>Source position: objpash.inc line 196

kuj>>type IInterface = IUnknown;
kuj>>Description

kuj>>IInterface is the basic interface from which all COM style interfaces descend."


kuj>>hattab, хватит уже расширять свое сознание.

H>ignore off

H>Я и сказал, что IInterface это идентичный IUnknown тип. Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать

H>ignore on


Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит

Здравствуйте, hattab, Вы писали:

H>Я и сказал, что IInterface это идентичный IUnknown тип.

Ликбез: IInterface — наследник IUnknown.

H>Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать

Ты разберись со "стейками для чайников" потом будешь говорить что мне делать, ок?

Здравствуйте, Mamut, Вы писали:

M>Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит

Это верно с одним но — оба интерфейса автоматически наследуют все методы родительского интерфейса IUnknown: AddRef, Release, QueryInterface.

Здравствуйте, hattab, Вы писали:
H>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах.

Вызов функции — это сброс конвейера. Ничего хорошего в этом нет.

Здравствуйте, Mamut, Вы писали:

H>>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.

M>Для таких случаев делается wrapper-объект, который содержит старый объект в виде приватной переменной. И?

В .NET и Java в таком случае обычно используется IoC/DI контейнер: класс зависит только от интерфейса, а любую новую имплементацию можно в любой момент зарегистрировать в runtime или в файле конфигурации — без каких-либо модификаций в коде.

Здравствуйте, hattab, Вы писали:

H>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах. А теперь прикинь, как нечасто вызываются эти функции.

Немного пугает лёгкость с которой ты бросаешься терагерцами.

Здравствуйте, Mamut, Вы писали:

H>>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.

M>Для таких случаев делается wrapper-объект, который содержит старый объект в виде приватной переменной. И?

Да-да, все сводится к рождению своего Query-blah-blah-blah

Здравствуйте, Mamut, Вы писали:

H>>>>Значит семантика у них идентичная и все тут. Можно у второго поменять IUnknown на IInterface, но разницы не будет ибо это идентичные типы.

kuj>>>"In programming, the IUnknown interface is the fundamental interface in the Component Object Model (COM). The published COM specification mandates that COM objects must minimally implement this interface. Furthermore, every other COM interface must be derived from IUnknown."

kuj>>>"IInterface

kuj>>>Basic interface for all COM based interfaces
kuj>>>Declaration

kuj>>>Source position: objpash.inc line 196

kuj>>>type IInterface = IUnknown;
kuj>>>Description

kuj>>>IInterface is the basic interface from which all COM style interfaces descend."


kuj>>>hattab, хватит уже расширять свое сознание.

H>>ignore off

H>>Я и сказал, что IInterface это идентичный IUnknown тип. Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать

H>>ignore on

M>Все мои знания по ООП говорят мне, что оба раза мы создали COM-объект, унаследовавшись от базового COM-интерфейса. То, что второй объект не имеет методов, доступных из других COM-обхектов (в частности, они не используют стандартные COM-типы), никак этому факту не противоречит

У интерфейсов нет понятий видимости или невидимости методов. Интерфейс рассматривается только в целом. Тот факт, что второй интерфейс не совместим с типами COM, делает его не COM интерфейсом.

Здравствуйте, kuj, Вы писали:

H>>Я и сказал, что IInterface это идентичный IUnknown тип.

kuj>Ликбез: IInterface — наследник IUnknown.

В статейках для чайников еще и не такое пишут. IUnknown = IInterface; (system.pas; line: 257)

H>>Тебе чего-то не понятно? Сперва разберись с моим примером на INonCOMInterface, а потом будешь мне статейки для чайников цитировать

kuj>Ты разберись со "стейками для чайников" потом будешь говорить что мне делать, ок?

Прекрати идиотничать.

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, hattab, Вы писали:
H>>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах.

MC>Вызов функции — это сброс конвейера. Ничего хорошего в этом нет.

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