Подключение библиотек. Visual C++

[Natalie]

Помогите, пожалуста!!!
Посоветуте где почитать, может быть...

[Джон]

По-подробнее пожалуйста. О чём речь? О подключении библиотек в виде .h .lib .dll
к проекту. Или о динамической подгрузке DLL? Какая студия? 6я или .NET?

[Natalie]

Я имела ввиду db library к SQLserv, но и это не все, еще сталкиваюсь с lib не знаю что делать...
Студия 6.

[Джон]

"db library к SQLserv" никогда такого не делал, может в разделе Базы данных спросить?

А вообще-то подключение довольно простая штука.

Речь идёт о том, где твои функции или классы объявлены. В СРР или LIB.
Поэтому тебе нужны 3 файла (если статическая LIB, то 2).
Например у тебя есть комплект:
MyLIb.h
MyLIb.lib
MyLIb.dll

который находится на в папке MyProject\mylib (проект находится MyProject\myexe - это для примера, чтоб показать использование пути)

Чтоб подключить в 6ой версии, идём в настройки проекта (Alt+F7) -> C/C++

Выбираем категорию Preprocessor и вводим дополнительнй путь (3 окошко ввода сверху)
../MyLib

это позволит делать #include без указания пути - в нашем случае
#include <MyLib.h> вместо #include "..\\MyLib\\MyLib.h"

Переходим на страничку настроек Linker. Выбираем категорию Input (Ввод)
если в списке используемых библиотек уже что-то стоит, то добавляем через пробел :!:  нашу библиотеку:

kernel32.lib user32.lib gdi32.lib winspool.lib MyLib.lib

можно сразу указать путь к ней - "../MyLib/MyLib.lib" ,  но ( если планируется использовать несколько LIB) лучше это сделать в соответствующем месте - доп. пути для библиотек.

Вписываем туда ../MyLib

Нажимаем Ок.

Теперь достаточно инклудировать MyLib.h (например в stdafx.h) и доступ к функциям и классам этой библиотеки готов.

Примечания:
1. Если используется несколько библиотек и они лежат в разных местах, то необходимо перечислить все пути к h- и lib-файлам, через запятую. И все lib-файлы через пробел.

2. Если есть различные конфигурации проекта (напр. Debug и Release), то необходимо выполнить подключение библиотеки в каждой конфигурации.

3. Если вариант с DLL, после сборки она должна находится там, где находится ЕХЕ.

[Natalie]

Спасибо за консультацию!!!!
Спасибо огромное!!!!
Но пока я металась в поисках ответа наткнулась на нечто мне не знакомое... Скажите имеет ли эта строка какое-либо отношение к теме??? :idea: #import "msado15.dll"
Я просто впервые увидела в проге #import...  
Если я не в тему, то простите!!!
Я очень Вам благодарна!!!

[Serega]

msado15.dll это COM-сервер, набор обьектов ADO для доступа к базам данных
директива #import извлекает из файла библиотеку типов (описание обьектов, интерфейсов, структур, перечислений) и создает два файла: заголовки(.h) и реализация(.cpp)
в .h описание всех обьктов и интерфейсов,  структур, перечислений,  и смарт пойнтеров (оборток для удобной работы с COM обьектами)
в .cpp код смарт пойнтеров и все GUID'ы

как приду на работу смогу прислать пример как этим пользоваться

[Джон]

Natalie,  Ну во-первых, мы тут вроде все на ТЫ, так что перестраивайся.

Директива #import предназначена для использования т.н. библиотек типов, которые обычно представляют собой СОМ интерфейсы. Проще говоря это позволяет получить доступ к уже существующим модулям (например Excel, Word и тд).

Те можно предположить, что твоя прога работает с базой данных используя её родные методы и классы.

Вчера я "умолчал" о другом способе подключения LIB файлов, который более "сложный" и не такой визуальный.

использование прагмы с параметром comment
#pragma comment(lib,"MyLib.lib")

Так что, если "такое" увидишь, то это тоже относится к теме. Обычно таким образом подготавливаются библиотеки и, тогда, тебе достаточно инклудировать
только #include <MyLib.h>, в котором стоит эта строчка. Но этот метод требует установки путей в настройках VS. Проще говоря, если у тебя есть только один .h файл, проверяешь его на наличие такой прагмы. Если есть, то значит о подключении библиотеки уже позаботились.

[Natalie]

Спасибо огромное, еще раз, за внимание и понимание.
Тем более это для меня ценно, что в радиусе 200км не наблюдается С++ ориентированных программеров.
Джон,
Если я перейду на «Ты», то как тогда высказать свое уважение к Вам и Вашим знаниям??? Хотя, я попробую… говорят же, в чужой монастырь со своим уставом…
А не визуальные методы я люблю больше всего… У меня проблемы с визуальными…
Приду домой пошарюсь по .h файликам…. спасибо.
Serega,
Благодарю за пояснение, у меня действительно идея фикс – подключиться и поработать с базой данных на SQLserv.
Но в связи с Вашим пояснением у меня возник еще один вопрос: если .dll раскладывается на .h и .cpp, то наверное это делается один раз и тогда в приложение вставлять такую строчку не надо? Ее нужно выполнить один раз? (И получим еще плюс два файлика в той же директории???)  И зачем тогда .lib? (простите, за глупый вопрос. )
И еще, мне очень хочется, чтоб при запуске приложение требовало имя базы данных, логин и пароль. Не подскажите, какими функциями это реализуется? Это, конечно, не в тему…  Создать новую в базах данных???

[Serega]

Мы с Джоном говорим о разных вещах,а тебе вообще нужно просто соединиться с базой данных

Начну с того что такое lib.
В операционной системе существуют файлы называемые динамически подгружаемые библиотеки
Это значит что программа во время исполнения может загрузить такой файл к себе в память и вызывать оттуда функции
В Windows такие файлы называются Dynamic-Link Library (DLL)
Для работы с ними существуют две функции:
HMODULE LoadLibrary(LPCTSTR lpFileName);
 - получает имя файла DLL, загружает его в память и возвращает идентификатор библиотеки
FARPROC GetProcAddress(HMODULE hModule, LPCSTR lpProcName);
 - получает идентификатор библиотеки и название функции, возвращает указатель на функцию

Чтобы вызвать функцию из DLL нам нужно сначала загрузить библиотеку, потом получить адрес нужной функции, затем полученный указатель преобразовать к нужному нам типу, т.к. FARPROC это
typedef int (*FARPROC)(void);

в общем мороки хватает и поэтому конечно же было придумано более простое решение - .lib
Это обьектный файл в котором находится код, избавляющий нас от необходимости вручную загружать DLL
При создании DLL помимо самой библиотеки можно создать .lib и .h файлы (в .h находятся заголовки экспортируемых функций)
И в программе использующей эту DLL нужно просто инклудить .h и слинковать .lib (добавить его либо в настройках проекта либо с помощью pragma)
но тут есть и свои минусы:
смещение функций внутри файла в этом случае определяется не динамически (с помощью GetProcAddress), а вычисляется на момент создания DLL, поэтому если DLL обновят и смещения функций изменятся то наша программа будет вылетать с Runtime Error
Поэтому какое решение выбрать зависит от конкретной ситуации

Ну вот вроде обрисовал в общих чертах что такое lib и для чего это вообще
следующая тема :arrow:

[Serega]

Теперь поговорим об import

DLL - это модель повторного использования кода (мы один раз её создали, и кто угодно может её использовать, вызывая нужные функции)
но к сожалению из DLL можно вызывать только функции, а мы уже давно пишем не на функциональных языках а на обьектно-ориентированных
Поэтому MS разработали обьектно-ориентированную модель повторного использования кода и назвали её Component Object Model (COM)
В этой модели мы работаем не с функциями а с обьектами, мы можем создавать их и вызывать их методы

Технологию DLL конечно не забыли и стали использовать DLL'ки для хранения кода COM обьектов

Но помимо файла с кодом COM обьектов нужно еще и описание этих обьектов:
 - его уникальное имя, а точнее номер (CLSID), чтобы мы случайно не создали другой обьект
 - какие интерфейсы поддерживает обьект, чтобы знать что мы можем с ним сделать
 - описание интерфейсов - какие есть методы, какие параметры у методов (интерфейс тоже идентифицируется уникальным номером - IID)
 - описание структур и перечислений, которые помимо базовых типов вполне могут использоваться в качестве параметров

Все это назвали библиотекой типов, а также решили что надобы модель сделать языконезависимой и стали писать библиотеки типов на языке IDL (синтаксис очень похож на C), и при использовании транслировать её в код конкретного языка

Не стану описывать все внутренности работы COM, а то целая статья получится

Нам важно то, что имея DLL'ку мы можем получить библиотеку типов и транслировать её в код С++
Именно этим и занимается #import

Для начала узнаем как работать с COM ручками

Для работы с COM существует парочка функций:
HRESULT CoInitialize(LPVOID pvReserved);
 - инициализация сервисов COM, должна быть вызвана до начала работы с COM
void CoUninitialize();
 - завершение работы
HRESULT CoCreateInstance(REFCLSID rclsid, LPUNKNOWN pUnkOuter, DWORD dwClsContext, REFIID riid, LPVOID * ppv);
- создает нужный нам обьект и возвращает указатель на нужный нам интерфейс

Все обекты COM поддерживают интерфейс IUnknown, у которого всего три метода:
ULONG AddRef(void);
 - добавить ссылку на обьект
ULONG Release(void);
 - удалить ссылку
HRESULT QueryInterface(REFIID iid, void ** ppvObject);
- запросить у обьекта нужный нам интерфейс

Да, обьект COM живет до тех пор, пока на него есть хотя бы одна ссылка, он хранит у себя счетчик ссылок, и как только тот обнуляется обьект удаляет себя из памяти

Ничего сложного в общем-то нет, но много ручной работы (что приравнивается к головной боли)

И конечно же было найдено решение - сделали обертки для интерфейсов - умные указатели
Умные указатели на COM интерфейсы реализуются с помощью класса _com_ptr_t

#import помимо извлечения библиотеки типов и трансляции её на C++ также создает умные указатели для всех интерфейсов

вот практически и все, больше голова не хочет работать, у меня 3:00

[Serega]

Завтра напишу что такое ADO

Вкратце это набор COM обьектов для доступа к базам данных

[Natalie]

Serega,
Спасибочки... Вы, пишите... пока я соображаю...
Но вот написание таких текстов в 3:00 - это круто...
Я конечно понимаю, что программеры люди особые... но так себя мучать??? :?:

[Serega]

Просто друг из армии пришел, вот мы и посидели немного

[Natalie]

Джон,
я пролистала  .h файлы и снова меня мучают разные мысли.. (характер наверное вздорный... )
Если при помощи использования  pragma с параметром comment можно заранее позаботиться о подключении библиотеки, то почему это не делается во всех .h файлах?
Не подумай, что я невнимательно читала Твое пояснение... про указание пути в настройках я помню, но почему бы не размещать эти файлы стандартно, в одном каталоге? Когда Ты говорил об указании пути в настройках, это имелся ввиду путь к .lib файлу? Так почему бы все .lib просто не помещать в директорию \lib?
Serega,
я осмысливаю и усваиваю... Ты не против, если я завтра задам еще пару вопросов?

[Serega]

Конечно не против
Помещать все файлы в одно место идея харошая, но возникает проблема с версиями

[Natalie]

Serega,
Ты имеешь ввиду версии библиотек или версии студий... типа на одном рабочем месте много разных???
И еще, если ты говоришь о версиях библиотек, то зачем держать старые версии??? Или это на случаей если в новых чего то не работает???
Как друг, жив после ночного бдения?

[Гром]

Версии библиотек - к h файлам не относится версия студии разработки!

Где ж вопросы

[Natalie]

Гром,
Ваше величество,  
Да, полностью согласна, но библиотеки то могут обновляться, а следовательно и .h файлы, соответствующие этой библиотеке, должны обновиться... :?:

[Гром]

НЕ всегда - скажем - происходит стандартный фикс багов при котором заголовки не сменились

[Гром]

Да и потом - речь шла об разработке т.е. о состоянии еще в исходниках!

[Serega]

Друг жив
Уехал дослуживать оставшиеся 2 месяца

[Serega]

Natalie, с тобой интересно общаться, не каждый день находится человек задающий интересные вопросы и по делу :!:
А имел я ввиду вот что:
допустим мы написали библиотеку mylib, и у нас есть 3 файла: mylib.dll, mylib.lib, mylib.h, это наша первая версия билиотеки
у нас есть программа написанная с использованием нашей библиотеки версии 1.0
потом мы написали версию 2.0, в которой немного изменили названия функций и их параметры
теперь чтобы наша программа не перестала компилироваться нам надо либо по другому назвать файлы новой версии библиотеки либо просто заменить старые файлы новыми и переписать программу под новую версию
думаю переписывать работающий никому не хочется, значит будем называть по-новому, допустим к имени файла будем дописывать номер версии, например так mylib2.dll
теперь у нас вместо 3-х файлов уже 6, и это только основные версии, а могут быть и промежуточные и для них тоже надо придумать систему именования, но это в принципе мелочи, достаточно подумать один раз
в принципе такой подход достаточно удобен если среда разработки ведет контроль версий и позволяет дописывать номер версии к названию
и в любом случае лучше куча файлов в одном месте, чем если бы они были разбросаны по всему винту

[Джон]

Natalie,  

1. На "Ты" с большой буквы - это класс! Можно так выразиться - "вежливо тыкать"   . Короче сам напросился.

2. Теперь про мысли... В принципе тебе тут не дают скучать (тем паче, что с базами данных я не игрался, тут уступаю слово Серёге ). Просто хочу добавить про библиотеки. На самом деле всё гораздо проще. Есть два пути подключения внешних модулей (эт я чтоб не писать lib и dll) к проекту в студии. Первый - назовём его глобальный. Это когда в настройках выставляются глобальные пути к lib h exe dll файлам а также файлам исходных кодов (те это не обязательно должны быть lib-ы). Эти настройки делаются в независимости от проекта. И всегда будут опрошены на предмет наличия необходимых ресурсов. Таким путями являются пути к MFC SDK WTL и тд пример:
"стандартный" набор в моей "шестёрке"
C:\Programme\Microsoft Visual Studio\VC98\INCLUDE
C:\Programme\Microsoft Visual Studio\VC98\MFC\INCLUDE
C:\Programme\Microsoft Visual Studio\VC98\ATL\INCLUDE

эта строчка добавилась после инсталляции платформы SDK
C:\Programme\Microsoft SDK\include

а эту я вставил вручную для поддержки WTL
C:\PROGRAMME\MICROSOFT VISUAL STUDIO\VC98\WTL\INCLUDE

Итак, пользователь зачастую даже не подозревает об использовании этих глобальных путей и модулей (ошибки типа - на моём компе всё работает, а вон на том нет). Необходимые h файлы и define уже как правило вставлены в код мастером проекта.

Глобальный способ нужен для часто используемых вещей, от которых зависит жизнь многих проектов. Было бы неудобно каждый раз проводить вручную одни и те же настройки. Поэтому и используется способ "уменьшения" видимой информации. Когда окнечный пользователь видить, что-нить типа #include <MyLib.h> и всё.

Второй - соответственно локальный способ (механизм которого я приводил)- применяется в единичных случаях, когда настройки для каждого проекта производятся в отдельности, да мало сказать для проекта, для каждой версии, компиляции и тд (Debug,Release, Unicode). Ведь не обязательно, что для релиза и дебага испльзуется одна версия lib. Например могут быть МyLib.lib и MyLibD.lib соответственно. И тем не менее у них один и неизменный h файл.

Объективно конечно трудно сказать, что лучше, а что хуже. Как говорится Cuique sum, что в вольнои переводе означает Кесарю кесарево, а слесарю слесарево.   Так что можно делать и так:
 

Так почему бы все .lib просто не помещать в директорию \lib?

и по-другому в зависиости от ситуации.

зы Ох и наплёл про лес .

Serega,  А вот по ночам не спать - это заразно? До твоих 3х я наверно не дотяну.

[Джон]

Гром, а часы-то барахлят. Уже 02:33

[Natalie]

Доброго дня Вам, Уважаемые господа программеры.
Сейчас я буду по быстрому портить впечатление о себе глупыми вопросами...
К сожалению последние Ваши комментарии прочесть не успела...
Может в них все ответы???
Прошу прощения, еще раз за собственную глупость и неуспевание...
Гром,
К сожалению, я полный день на работе, (администрю потихонечку... и это с моими то знаниями... () а читаю умные книги и советы только дома, вечером, ночью... а потому и вопросы формируются с регулярностью в одни сутки... Хотелось бы чаще, но не могу бросать на произвол судьбы своих пользователей... как никак – движущая сила любой автоматизации – люди, операторы, специалисты, а когда они чувствуют себя «брошенными», то работают хуже... итог моей работы, в данный момент, зависит от их усилий не менее, чем на 80%.  
Я периодически почитываю Вашу рассылку, но никогда не думала, что можно задать вопрос Вам непосредственно... ) А собака у Вас – СУПЕР!!!! Как Вы с ней ладите? (это первый вопрос:)))
Serega,
Спасибо за такое подробное пояснение, от смущения за свое не знание, хочется спрятать голову в песок, как страус... )) но, что делать, как кто-то сказал, асфальт кругом.
1. Что значит: «идентификатор библиотеки» -это что-то типа ссылки на область памяти, в которую загружена библиотека?
2. И что значит фраза: «полученный указатель преобразовать к нужному нам типу»
Каким образом, получив такой указатель, можно преобразовать его к другому типу? (имеется ввиду полное определение вызываемой функции? т.е возвращаемое и требуемые значения?)
3. «его уникальное имя, а точнее номер (CLSID), чтобы мы случайно не создали другой обьект» Можно поподробнее про CLSID??? Т.е. создание объектов каким-то образом стандартизировано?
4. Ты обещался про ADO рассказать поподробнее... pls.
Идея (не моя в корне) состоит в том, что я рассчитывала строить подключение через ODBC... Это все каким-то образом завязано???

[Serega]

Вечером обязательно отвечу на все вопросы, а сейчас убегаю на работу

[Джон]

Народ. Пора заканчивать по-ночам писать. Я ща тему еле нашёл (хорошо хистори исправно работает). А всё почему? Да потому что она в "Java" :!:

Эй хто нибудь из админов - перенесите в С++ для ОС.

[Natalie]

Джон,
Спасибочки... все понятно, доступно и вполне разумно...    Хотя для ночи, это все ж нонсенс...    Что-то подхватил нас всех ветерок ночных бдений...  
Короче, тот вопрос из-за которого я так расстраивалась получил более чем достойный ответ...  8)
Но проблема в том, что у меня других вопросов много!!! А еще мне очень понравилось с вами общаться...    Я просто счастлива, что Вы такие добрые, хорошие и умные!!! Вот.  

Serega,
Армия... это же еще до ВУЗА... я не ошибаюсь?  
И правда, говорят, что все от человека зависит!!!  
Такие знания добытые самостоятельно - это СУПЕР!!! /*продолжаю удивляться*/  

А вот теперь по теме... :?
Я тут по ночам усиленно просвещаюсь и иногда встречаю в текстах идеи, которые меня пугают...
Например:
1. #import "C:\Program Files\Common Files\System\ado\msado20.tlb" \
        rename("EOF","ADOEOF") rename("BOF","ADOBOF")
"... атрибут rename, его необходимо использовать, когда возникают конфликты имён свойств и методов библиотеки типов с препроцессором."
Это что же, надо наизусть знать все имена свойств и методов библиотеки, а так же все подобное во всех подключаемых .h файлах? А самое главное, вовремя и адекватно отреагировать, - не забыть переименовать?
Что-то здесь "не чисто"...
Я понимаю, что моя человеческая оперативка оставляет желать лучшего, но неужели это так фатально?
Нет, я только ЗА, что нужно "от корки до корки" знать подключаемую библиотеку... но как-то это... :new_shot:

2.  "Чтобы клиент мог получитть доступ к COM объекту, тот должен быть зарегистрирован в реестре Windows. " .... оопс.. еще один прикольчик!!!
Снова нюанс, который требует пояснения... :!:
Нет, все понятно, когда библиотека содержит свой инсталлятор, как и выше упомянутая db library, а если не содержит??? как прописываются в реестре библиотеки??? :?:

3. "В частности, в реестре прописываются CLSID и IID." - кто придумывает эти уникальные идентификаторы??? программер создающий library??? Где тогда гарантия, что они будут действительно уникальны??? :?:

[Natalie]

Джон,
Странно... я вроде в разделе "для начинающих" вопросик задала. :?:

[Serega]

наизусть знать конечно ничего не нужно (вообще много знать вредно =)
в случае чего компилятор тебе всегда напомнит