В предыдущем IDL на каждый
В предыдущем IDL на каждый из интерфейсов IApe, IWarrior, IEgghead и IKeeperOfTheFaith есть ссылки из определения библиотеки. По этой причине их определения присутствуют в генерируемой библиотеке типов, несмотря та то, что они определены вне области действия определения библиотеки. В действительности любые типы данных, используемые как параметры или как базовые интерфейсы для данных интерфейсов, будут в то же время присутствовать в генерируемой библиотеке. Существует хорошая практика — определять оператор с реализацией библиотеки в отдельном IDL-файле, который импортирует все необходимые определения интерфейсов из внешнего IDL-файла, содержащего только описания интерфейсов. Такая практика является обязательной в больших проектах со многими IDL-файлами, так как для IDL-файла, содержащего определение библиотеки, недопустимо импортировать другой IDL-файл, который также содержит определение библиотеки. Путем разделения определений библиотеки по отдельным IDL-файлам можно корректно импортировать интерфейсы, используемые библиотекой, в другие проекты, не беспокоясь о множественных определениях библиотеки. Если не использовать этот способ, то существует только одна возможность импортировать определение интерфейса из IDL-файла, содержащего определение библиотеки, — использовать директиву importlib:
// humans.idl // apeitfs.idl DOESN'T have a library statement, so import // apeitfs.idl HE ИМЕЕТ оператора library, поэтому импортируем import "apeitfs.idl"; [ uuid(753A8AC9-A7FF-11d0-8C30-0080C73925BA), version(1.0), lcld(9), helpstring("Humans that need apes") // "Люди, нуждающиеся в обезьянах" ]
library HumanLib { importlib("stdole32.tlb"); // bring in std defs. - вносим стандартные определения // Dogs.idl DOES have a library definition, so importlib // its corresponding type library // Dogs.idl ИМЕЕТ определение библиотеки, поэтому // импортируем библиотеку соответствующего типа importlib("dogs.tlb"); [uuid(753A8AD1-A7FF-11d0-8C30-0080C73925BA)] coclass DogApe { interface IDog; interface IApe; } }
В простых проектах часто используется один IDL-файл, в котором определяются как интерфейсы, так и классы, экспортируемые из проекта. Для простых интерфейсов это имеет смысл, так как генерируемая библиотека типов будет содержать взаимно однозначные образы исходных определений IDL, что позволит пользователям этой библиотеки применять importlib без потери информации. К сожалению, в случае сложных интерфейсов многие из исходных IDL-измов (IDL-ism) теряются в результирующей библиотеке типов, и тогда importlib не будет работать так, как хотелось бы. Грядущая версия компилятора MIDL, быть может, будет способна генерировать библиотеки типов, которые будут содержать все из исходного IDL.
Содержание Назад Вперед
Forekc.ru
Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий