Программирование на Visual C++. Архив рассылки, Jenter Алекс

Программирование на Visual C++. Архив рассылки

на обложку

Jenter Алекс

Шрифт:

Главное достоинство CLR – всепроникающая, расширяемая, качественная информация о типах. В CLR все типы – а не только экспортированные из компонента – имеют runtime-описания типов. В CLR вы можете перейти к любому объекту и исследовать каждый аспект его определения типов, включая его представление. Это фундаментальный отход от классического COM, где открытые (public) интерфейсы были доступны, но представление объекта было скрыто.

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

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

Попробуем подытожить вышесказанное, перечислив усовершенствования, внесённые CLR в компонентную модель, попутно сравнивая эти усовершенствования с уже имеющимися в COM и других компонентных и околокомпонентных архитектурах.

Сборки. Сборки, или в оригинале Assembly – это логическая коллекция типов, описывающая объекты, которые могут быть реализованы в нескольких модулях (DLL или EXE). Сборка определяет область имен (типов), снимая надобность в GUID-ах для каждого типа. Так как имена сборок не могут повторяться, коллизии имен типов случиться также не может.

Для компонентов, используемых в рамках одного приложения, имена файлов сборки достаточно уникальны. CLR-сборки, в которых содержатся разделяемые компоненты (используемые совместно несколькими приложениями), можно присвоить (strong names). Строго именованная сборка имеет 128-битный публичный ключ, который идентифицирует разработчика компонента. Когда программа-клиент связывается со строго именованной сборкой, 64-битный хеш публичного ключа сохраняется в метаданных этой программы. Во время исполнения публичный ключ сборки сравнивается с 64-битным хешем, хранящимся в метаданных клиента, обеспечивая загрузку нужной сборки.

В COM для обеспечения уникальности почти каждому типу соответствует 128-битный GUID. В CLR каждая сборка имеет 128-битный публичный ключ, что, в сочетании с локально уникальными символьными именами типов, обеспечивает глобальную уникальность описания типов. Оба способа дают примерно одинаковый эффект, но способ CLR позволяет избежать работы с GUID– ами внутри приложений.

Единый стандарт обмена метаданными. Как уже говорилось раньше, информация о типах в COM передавалась в текстовой (IDL, заголовочные файлы) или в бинарной (TLB) форме. В CLR, напротив, информация о типах всегда передается в одной и той же документированной бинарной форме. Все работающие с CLR средства и компиляторы выдают и принимают метаданные в этом формате. Так, при определении набора интерфейсов разработчик может использовать свой любимый язык программирования и компилятор для создания описаний типов, вместо того, чтобы использовать один синтаксис (IDL) при описании типов и другой (например, C++ или Visual Basic) при их реализации.

Доступность метаданных во время исполнения. Из постулата единого формата метаданных вытекает доступность метаданных в runtime, даже если во время разработки метаданные доступны не были. Причем можно не только читать, но и писать метаданные (создавать новое описание). Это дает возможность создавать динамически расширяемые приложения, позволяющие использовать информацию о типах для подключения внешних модулей или динамического вызова методов и установки свойств. Одним словом предполагается, что такие сложные приложения, как контейнеры объектов (дизайнеры форм, менеджеры транзакций и т.п.) можно

будет писать на любом языке программирования, даже на VB. Более того, описание, сделанное на одном языке, можно будет использовать в другом без каких либо дополнительных действий. Еще более того, можно будет наследовать классы одного языка от классов, описанных на другом языке.

Например, рассмотрим следующий COM IDL:

[ uuid(ABBAABBA-ABBA-ABBA-ABBA-ABBAABBAABBA) ]

library MyLib {

importlib("stdole32.tlb");

[ uuid(87653090-D0D0-D0D0-D0D0-18121962FADE) ]

interface ICalculator : IUnknown {

HRESULT Add([in] double n, [in, out] VARIANT_BOOL *round, [out] VARIANT_BOOL *overflow, [out, retval] double *sum);

}

Эквивалентный тип CLR на C# (это новый язык программирования, который претендует стать основным языком VS.Net, о нем мы еще подробно поговорим позже) будет выглядеть так:

namespace MyLib {

interface ICalculator {

double Add(double n, ref bool round, out bool overflow);

}

Если поместить это описание в файл, то его можно будет скомпилировать с помощью компилятора C#, следующей командной строкой:

csc.exe /t:library /out:mylib.dll mylib.cs

Полученное бинарное описание можно импортировать, например, в VB, используя ключ компилятора "/r":

vbc.exe /r:mylib.dll program.vb

CLR не снимает необходимости определения типов, он позволяет разработчику делать это на любом языке, совместимом с CLR.

CLR предоставляет библиотеку, позволяющую в runtime-е читать и/или создавать сборку, содержащую описание типов. Нижеприведенный листинг демонстрирует создание сборки, содержащей описание следующего интерфейса:

namespace MyLib {

public interface ICalculator {

double Add(double n, ref double round, out double overflow);

}

Код, создающий сборку, реализован на C#, языке, похожем на C++ или Java. Мы надеемся, что у вас не возникнет проблем с пониманием кода:

using System;

using System.Reflection;

using System.Reflection.Emit;

public class emititf {

// Точка входа программы (объектно-ориентированный аналог функции main в С/C++)

public static int Main(String[] argv) {

// Создаем новую сборку AssemblyBuilder ab = DefineNewAssembly;