При компиляции клиентского VC-приложения в подключенном
к проекту заголовочном файле dll (ImplicitLinking_cdecl.h) к наименованию
каждой функции с помощью директив #define добавляется символ подчеркивания
(макрос _MSC_VER определяется компилятором VC по умолчанию). Поскольку из BCB
dll __cdecl-функции экспортируются таким же образом, то есть с добавлением
символа подчеркивания, то устанавливается соответствие имен экспортируемых и
объявленных функций. Макросы #define распространяют свое влияние и на весь
последующий код приложения, что позволяет в тексте программы при вызове
импортируемой функции пользоваться ее оригинальным именем, которое при
компиляции будет дополнено необходимым магическим символом подчеркивания. Таким
образом, мы идем на поводу у фирмы Borland и в клиентском приложении завуалированно
используем для вызова функций из нашей dll имена, измененные компилятором BCB.
Именно необходимость использования измененных имен (пусть и не в открытую
благодаря define-трюку), на мой взгляд, является существенным недостатком этого
способа, так как, например, при желании явно (см. раздел “Алгоритм с явной
загрузкой dll”) использовать dll придется оперировать измененными именами
функций. Не развивая дальше эту тему, скажу, что если BCB dll создается с
четким намерением использовать ее в VC-приложениях, то лучше добавлять к
проекту библиотеки .def-файл с удобными для пользователей именами-псевдонимами
функций.
К достоинствам данного способа (define-трюка) можно
отнести его простоту и, как бы это ни противоречило сказанному в предыдущем
абзаце, отсутствие необходимости добавлять к таблице экспорта dll псевдонимы
функций. Несмотря на все удобства использования псевдонимов, таблица экспорта
(а следовательно, и сама dll) при этом увеличивается в размерах. Да и создание
.def-файла псевдонимов при большом количестве функций не добавляет приятных
эмоций.
После компиляции dll с помощью impdef.exe получаем
.def-файл экспорта, из которого утилитой lib.exe создаем объектный .lib-файл и
добавляем его к клиентскому VC-проекту.
Листинг клиентского приложения, код которого в данном
случае не зависит от способа решения проблемы несоответствия наименований
функций в заголовочном и объектном файлах библиотеки, представлен ниже. Как и в
предыдущем разделе, это диалоговое окно с двумя кнопками. Интересующий нас код
сосредоточен в обработчиках событий нажатия кнопок диалога.
Листинг 5 - Компилятор Visual C++ 6.0
UsingImplicitLinking_cdeclDlg.cpp
// код, генерируемый средой
разработки
…
// хэндл окна с
VCL-компонентом StringGrid
HWND hGrid = NULL;
// подключаем заголовочный
файл библиотеки
#include
"ImplicitLinking_cdecl.h"
Рекомендуем скачать другие рефераты по теме: инновационная деятельность, заключение дипломной работы.
