Късно подвързване. Късно свързване с COM компоненти

Късно робство с COM компоненти

Преди клиентският изпълним файл да може да извика методите и свойствата на съставен обект, той трябва да знае адресите на паметта на тези методи и свойства. Има две различни технологии, които клиентските програми могат да използват, за да определят тези адреси.

Ранно свързаните програми научават адреси в началото на процеса на компилиране/изпълнение – по време на компилация. Когато се компилира програма за ранно свързване, компилаторът използва библиотеката с типове на компонента, за да включи адресите на методите и свойствата на компонента в изпълнимия файл на клиента, така че адресите да могат да бъдат достъпни много бързо и без грешки. далеко използвайте ранно обвързване.

От своя страна програмите с късно свързване научават адресите на свойствата и методите късно в процеса на компилиране/изпълнение. в момента, в който се извикват тези свойства и методи. Късно обвързаният код обикновено осъществява достъп до клиентски обекти чрез основни типове данни, като например обект, и използва средата за изпълнение, за да определя динамично адресите на методите. Въпреки че кодът с късно свързване позволява използването на някои сложни техники за програмиране като полиморфизъм, той идва с някои свързани разходи, които ще видим скоро.

Но първо, нека проверим как се извършва късното свързване с помощта на отражение в C# (Отражението е начин, който кодът използва по време на изпълнение, за да определи информация за интерфейсите на класове от страна на сървъра; вижте глава 5.)

При късно свързване към COM обект в C# програма, не е необходимо да създавате RCW за COM компонент. Вместо това се извиква методът на клас GetTypeFromProgID на класа Type, за да създаде обект, който представлява типа COM обект. Класът Type е член на пространството от имена System.Runtime.InteropServices и в кода по-долу конфигурираме обект Type за същия компонент за достъп до COM данни, използван в предишните примери:

Тип objCustomerTableType;

Когато има Type обект, който капсулира информация за типа на COM обект, той се използва за създаване на екземпляр на самия COM обект. Това се постига чрез предаване на Type обект към метода CreateInstance на класа Activator.CreateInstance създава екземпляр на COM обект и връща късно свързваща препратка към него, която може да бъде съхранена в препратка към тип обект.

обект objCustomerTable;
objCustomerTable = Activator.CreateInstance(objCustomerTableType);

За съжаление, не е възможно да се извикват методи директно върху препратка от тип object. За да имате достъп до COM обект, трябва да използвате метода InvokeMember на обекта Type, който е създаден първи. Когато се извика методът InvokeMember, му се предава препратка към COM обект заедно с името на извиквания COM метод, както и масив от тип обект от всички входящи аргументи на метода.

ObjCustomerTableType.InvokeMember("Изтриване", BindingFlags.InvokeMethod, null, objCustomerTable, aryInputArgs);

Нека отново да си припомним последователността от действия:

1. Създайте обект Type за тип COM обект, като използвате метода на класа Type.GetTypeFromProgID() .

2. Използвайте този Type обект, за да създадете COM обект с помощта на Activator.CreateInstance() .

3. Методите се извикват на COM обект чрез извикване на метода InvokeMember на обекта Type и предаване на препратка към обект като входен аргумент. По-долу е примерен код, който комбинира всичко това в един блок:

използване на System.Runtime.InteropServices;
Тип objCustomerTableType;
обект objCustomerTable;
objCustomerTableType=Type.GetTypeFromProgID("DataAccess.CustomerTable");
objCustomerTable=Activator.CreateInstance(ObjCustomerTableType);
objCustomerTableType.InvokeMember("Изтриване", BindingFlags, InvokeMethod, null, objCustomerTable, aryInputArgs);
objCustomerTableType = Type.GetTypeFromProgID("DataAccess.CustomerTable");

Въпреки че функциите за късно свързване на C# избягват трудностите на RCW, има някои недостатъци, свързани с него.

Първо: късното свързване може да бъде опасно. Когато се използва ранно свързване, компилаторът може да направи запитване до библиотеката с типове на COM компонента, за да гарантира, че всички методи, извикани на COM обекти, действително съществуват. При късното свързване няма нищо, което да попречи на правописна грешка в извикването на InvokeMember() да причини грешка по време на изпълнение.

2

Да кажем, че няма функция Hello и ние просто извикваме ob.display основно, тогава тя извиква функцията за показване от клас B, а не от клас A.

Извикването на display() се задава веднъж от компилатора на версията, дефинирана в базовия клас. Това се нарича разрешаване на статично извикване на функция или статично обвързване - извикването на функцията се извършва преди изпълнението на програмата. Това също понякога се нарича ранно свързване, тъй като функцията display() е посочена по време на компилиране на програмата.

Сега, как може да извика функцията за показване на производния клас, без да използва виртуална ключова дума (късно свързване) преди функцията за показване в основния клас?

Сега в тази програма предаването на обекта като извикване по стойност, извикване чрез указател и извикване чрез препратка към функцията Hello работи добре. Сега, ако използваме Polymorphism и искаме да изобразим функция-член на производен клас, ако бъде извикана, трябва да добавим ключова думавиртуален преди функцията за картографиране на база данни. Ако предавате стойността на обект при извикване с помощта на указател и извикване по референция, това е извикване на функция в производния клас, но ако предавате обекта по стойност, това не е защо е така?>

Клас A ( public: void display(); // виртуален void display() ( cout<< "Hey from A" <display() ) int main() ( B obj; Hello(obj); // obj //&ob return 0; )

• 2 отговора

Сортиране:

Дейност

4

сега как може да извика функцията за показване на производния клас, без да използва виртуалната ключова дума (късно обвързване) преди функцията за показване в основния клас?

Невиртуална функция просто се разрешава от компилатора според статичния тип на обекта (или препратка или указател), който извиква. Така даден обект от производен тип, както и препратка към неговия подобект:

Bb; A&a=b;

ще получите различни резултати от извикване на невиртуална функция:

B.display(); // извиква се като B a.display(); // наречен като A

Ако знаете истинския тип, тогава можете да посочите как искате да наречете тази версия:

Static_cast (a).display(); // наричан като B

но това, което би било ужасно погрешно е, ако обектът a препраща няма тип B.

Сега, ако използваме Polymorphism и искаме да картографираме функция-член на производен клас, ако бъде извикана, трябва да добавим виртуална ключова дума преди функцията map в основата.

Поправям. Ако направите функция виртуална, тя ще бъде разрешена по време на изпълнение според динамичния тип на обекта, дори ако използвате различен референтен тип или указател за достъп до нея. Така че и двата горни примера биха го нарекли B.

Ако предадем стойността на обект чрез извикване чрез указател и извикване чрез референция, той извиква функцията в производния клас, но ако предадем обекта чрез стойност, това не означава защо е така?

Ако го предадете по стойност, тогава вие нарязваненеговото: копиране само на частта A от обект, за да се създаде нов обект от тип A. Така че, независимо дали тази функция е виртуална, извикването й на този обект ще избере версията на A, тъй като това е A и нищо друго освен A.

0

wikipedia казва, че нарязването на обекти се случва, защото няма място за съхраняване на допълнителни производни членове на класа в суперкласа, така че той се нарязва. Защо нарязването на обекти не се случва, ако го предадем по референция или указател? Защо суперкласът получава допълнително място за съхранение? -

• реч () - Крал.реч()
• реч (цитиране на низ) -Крал.реч (цитиране на низ)
• Крал.реч (Булев speakLoudly)

• реч () -Ерис Таргариен . реч()
• реч (цитиране на низ) -Ерис Таргариен. реч (цитиране на низ)
• реч (Булев speakLoudly) -Крал. реч (Булев speakLoudly)

1. Определя се действителният тип на променливатакрал . В случая е такаЕрис Таргариен.
2. Виртуалната машина определя класа, към който принадлежи методътреч()
3. Методът се нарича.

1. нов обект()
2. нов крал ()
3. новАерисТаргариен()

Въпреки това, динамично обвързано повикване може да отиде до "външната" част на йерархията, тоест до производни класове. Ако извика метод на производен клас в конструктора, това може да доведе до манипулиране на неинициализирани данни, което виждаме в изхода на този пример.

Резултатът от програмата се определя от изпълнението на алгоритъма за инициализация на обекта:

1. Паметта, разпределена за новия обект, се запълва с двоични нули.
2. Конструкторите на базов клас се извикват в реда, описан по-горе. В този момент се извиква замененият методреч() (да, преди да извикате конструктора на класаЕрис Таргариен), където се открива, че променливатажертваИме е нула заради първия етап.
3. Инициализаторите на членовете на класа се извикват в реда, в който са дефинирани.
4. Тялото на конструктора на производния клас се изпълнява.

1. Екел Б. -Мислене в Java , 4-то издание - Глава 8
2. Кей С. Хорстман, Гари Корнел - Core Java 1 - Глава 5
3. Уикипедия

В статията говорих за не всички познати функции, които може да срещнете, когато работите с вградени функции. Статията породи както няколко значими коментара, така и многостранични дебати (и дори holiwars), които започнаха с факта, че е по-добре изобщо да не се използват вградени функции, и се превърнаха в стандартната тема C vs. C++ срещу Java срещу. C# срещу. PHP срещу. Haskell срещу. ...

Днес е ред на виртуалните функции. И първо, веднага ще направя резервация, че моята статия (по принцип, както и предишната) по никакъв начин не претендира за пълна. И второ, както и преди, тази статия не е за професионалисти. Ще бъде полезно за тези, които вече разбират основите на C++, но нямат достатъчно опит, или за тези, които не обичат да четат книги.

Надявам се всички да знаят какво представляват виртуалните функции и как се използват, тъй като вече не е моя работа да обяснявам това. Сигурен съм, че RFry ще стигне до тях рано или късно в поредицата си от статии за C++.

Ако в материала за inline методите митът не беше съвсем очевиден, то в този е точно обратното. Всъщност, нека да преминем към „мита“.

Виртуални функции и ключова дума virtual

1. #включи
2. #включи
3. използване на std::cout;
4. използвайки std::endl;
5. структура А
6. виртуален ~A()()
7. << "A::foo()" << endl; }
8. << "A::bar()" << endl; }
9. void baz() const ( cout<< "A::baz()" << endl; }
10. структура B: публична A
11. виртуален void foo() const ( cout<< "B::foo()" << endl; }
12. void bar() const ( cout<< "B::bar()" << endl; }
13. void baz() const ( cout<< "B::baz()" << endl; }
14. структура C: публична B
15. виртуален void foo() const ( cout<< "C::foo()" << endl; }
16. виртуален void bar() const ( cout<< "C::bar()" << endl; }
17. void baz() const ( cout<< "C::baz()" << endl; }
18. int main()
19. cout<< "pA is B:" << endl;
20. A * pA = нов B;
21. pA->foo();
22. pA->bar();
23. pA->baz();
24. изтриване на pA;
25. cout<< "\npA is C:" << endl;
26. pA = нов C;
27. pA->foo(); pA->bar(); pA->baz();
28. изтриване на pA;
29. връщане EXIT_SUCCESS;

И така, имаме проста класова йерархия. Всеки клас дефинира 3 метода: foo(), bar() и baz(). Нека помислим грешна логикахора, които са под влияние мит:
когато указателят pA сочи към обект от тип B, имаме резултата:

pA е B:
B::foo() // защото в родителския клас A методът foo() е маркиран като виртуален
B::bar() // защото в родителския клас A методът bar() е маркиран като виртуален
A::baz() // защото в родителския клас A методът baz() не е маркиран като виртуален

pA е C:
C::foo() // защото в родителския клас B методът foo() е маркиран като виртуален
B::bar() // защото в родителския клас B методът bar() не е маркиран като виртуален,
// но е маркиран като виртуален в клас A, указателят към който използваме
A::baz() // защото в клас A методът baz() не е маркиран като виртуален

Всичко е ясно с невиртуалната функция baz(). Но има проблем с логиката на извикване на виртуални функции. Мисля, че от само себе си се разбира, че действителният резултат ще бъде:

pA е B:
B::foo()
B::bar()
A::baz()

PA е C:
C::foo()
C::bar()
A::baz()

Заключение: виртуална функция става виртуална до края на йерархията и ключовата дума виртуалене „ключ“ само първия път, а в следващите пъти носи чисто информативна функция за удобство на програмистите.

За да разберете защо това се случва, трябва да разберете как точно работи механизмът на виртуалната функция.

Ранно и късно връзване. Таблица с виртуални функции

След като се натъкна на ключовата дума virtual, компилаторът отбелязва, че късното свързване трябва да се използва за този метод: първо, той създава таблица с виртуални функции за класа и добавя нов член, скрит за програмиста към класа - указател към тази таблица . (Всъщност, доколкото ми е известно, езиковият стандарт не предписва точно как трябва да се реализира механизмът на виртуалната функция, но внедряването, базирано на виртуална таблица, се е превърнало в стандарт де факто.) Помислете за този код за доказателство:

1. #включи
2. #включи
3. struct Empty();
4. struct EmptyVirt ( виртуален ~EmptyVirt()());
5. struct NotEmpty (int m_i;);
6. struct NotEmptyVirt
7. виртуален ~NotEmptyVirt() ()
8. int m_i;
9. struct NotEmptyNonVirt
10. void foo() const()
11. int m_i;
12. int main()
13. std::cout<< sizeof (Empty) << std::endl;
14. std::cout<< sizeof (EmptyVirt) << std::endl;
15. std::cout<< sizeof (NotEmpty) << std::endl;
16. std::cout<< sizeof (NotEmptyVirt) << std::endl;
17. std::cout<< sizeof (NotEmptyNonVirt) << std::endl;
18. връщане EXIT_SUCCESS;