Колко бързо (за мен) време за изпълнение - и сега сме на прага на IUnknown. Как бавно (за вас) време за изпълнение - ние просто имам нещо, само за да праг IUnknown. Но въпреки това, тук ние сме на прага на "сериозен COM".
Така че - IUnknown интерфейс е основният интерфейс, който се основава на COM. Той е длъжен да изпълни всеки COM обект на име, той е длъжен да присъства във всяка част на интерфейса, проявена обекта. Но IUnknown - много специален интерфейс, ако имаме предвид, не е неговата видимост от страна на клиента и неговото прилагане в рамките на предмета на сървъра. И основните характеристики на IUnknown смятаме за в тази статия.
Връзка е най-добре да се започне с точната спецификация. Точната спецификацията на IUnknown интерфейс се съдържа в файл C ++ глава име
IUnknown интерфейс е "GUID":
Защо методи IUnknown - подробно разглежда по-рано. Така че сега ние считаме, трябва да се прилагат само тези методи. Нека да започнем като се следва процедурата.
метод AddRef. Създаден, за да преминете на референтния брой. Трябва да се върне на новата стойност на референтния брой - 1 и N, но да използва тази стойност само за отстраняване на грешки. Microsoft казва, че понякога на стойността може да бъде "нестабилна". Което означава "нестабилна" - аз не знам. Очевидно има предвид, че в многонишкова среда точно брояч стойност, известна само на гишето, която е защитена срещу едновременен достъп едновременно от множество нишки. Но значението на текущата стойност на брояча, издаден по всяко поток може да се унищожават незабавно паралелен поток. В действителност, по смисъла на тезгяха от страна на клиента има наистина само за отстраняване на грешки, нищо друго не е възможно да се изгради върху тази стойност.
метод на издаване. Проектиран за насърчаване на връзките назад брояч единица. Връща нов (след спадане) стойността на референтния брой, което също може да се използва само за отстраняване на грешки цели. В този случай, ако броячът достигне нула - прилагането на метода е да се освободят средства, примитивно казано - да унищожи обекта.
И тук е необходимо да се обърне внимание - това AddRef и Освободете всеки интерфейс служи същия референтен броя - референтния брой на цялото съоръжение. Т.е. прилагане на тези методи и може да бъде един за целия обект.
Но тогава ще трябва да се мисли малко. Това, което се има предвид под фразата: "методът трябва да се освободят ресурси"? За прост в проектиране и моделиране на обекти е, разбира се, е еквивалентно на премахването на обекта, получен чрез новия сървър сделка. Но за сложни обекти, това не може да е вярно - (. Те се наричат откъсване "откъсване") някои интерфейси комплексен обект може да се приложи "отделно", т.е. не ги получаване на средства за създаване на обекта, и да получават средства само когато някой иска да го свържете с този интерфейс. В този случай, методите AddRef и изданието ще бъдат принудени да служат за двама и позоваване брой - общо за цялото съоръжение и частния точно за такива интерфейси, като част от обекта. И само незначително, тъй като обект на получаване на ресурси, на излизане ще ги освободи. В този случай, терминът "ресурси", имам предвид не само динамична памет. Например, прилагането на интерфейса може да отворите файл, за да се установи връзка с мрежата, и т.н. Тези ресурси трябва да се отделят в случай на загуба на всички връзки в интерфейса.
За някои обекти (и никога не се знае, а вие ще трябва да се прилагат такива съоръжения?), Както CBanzai обект на пример №1. което е статично ниво обект модул ", самостоятелно убиец" не е необходимо. Но референтния брой за този обект ще трябва да изпълняват както на клиента, така и за този индекс ще призове AddRef / излизане. въпреки че в този случай, нищо не прави. Принципът трябва да се поддържа - клиентът не знае как се изпълнява обекта на сървъра. Клиентът знае само интерфейса, през който тя си взаимодейства с обекта. И трябва да се съобразява с протокола.
Виждате ли - всичко е съвсем проста, рационален, разумен. Например, аз не виждам (това е след пет години използването на COM и писането на програми, да го използвате :) нищо неразбираемо - наличието на каквито и да било структурни характеристики, които открихме причината за което ние не може да се отърве от - поради което конструира и трябва да бъдат изпълнени.
Всъщност, сега можем да напише втория пример - примера, в които обектите на недостатъци в дизайна на първия пример ще бъдат коригирани механизъм софтуер, който току-що научих. Това ще направи нашите съоръжения наистина "реален COM обекти", но за съжаление все още не позволява да се отървете от CoCreateInstance емулатор - има малки COM обекти, които са необходими, че те са живели в "този COM -server". И от "този COM -Server" все още знаем само една от четирите реализира и да ги изложени на системни функции - DllGetClassObject. Ето защо, веднага след като разгледа дейността на примера, да преминем към следващата тема - проектиране COM -server. Подобаващ проучването случай "на COM обекти, на" философията ще бъде отложена за по-късно.
Свързани статии