Что лучше использовать #include или LoadLibrary?

Question

[Ternick]

Доброго времени суток :)
Искал в интернете, ничего особо понятного не написано.

Много вопросов

1) Откуда берёт библиотеки LoadLibrary ?
2) Проверяет ли LoadLibrary подпись библиотеки, если берёт её из системных путей ?
3) Уменьшится ли размер исполняемого файла если использовать только LoadLibrary, без #include ? {Один не в счёт, надо же как-то брать HMODULE, WINAPI и прочие штуки ...}
4) Что лучше использовать #include или LoadLibrary ?
5) Если библиотека существует и существует метод к которому я хочу обратится, может ли появиться ошибка ?

Comments

[AnT]

Ничего не понял. Вопрос бессмыслен. #include никак не заменяет LoadLibrary. Вы о чем вообще? Вопрос звучит как "что лучше, яблоко или прямой угол?"

[Ternick]

AnT, Не совсем. LoadLibrary загружает в память моего приложения Dll, затем GetProcAdress и в удачном исходе я получаю адрес на функцию нужную мне из dll и могу не использовать функцию которую я могу получить сделав #include.

[shurshur]

Ternick, вообще-то #include и LoadLibrary делают абсолютно разные вещи.

[Ternick]

shurshur, Да что вы ко мне все тут идёте, что-то объяснять без знания того о чём я спрашиваю.

[shurshur]

Ternick, #include служит для включения куска кода в другой файл (есть нюансы, но их не будем касаться). Обычно используется для деклараций функций, классов итд итп, сами функции при этом пишут в отдельном файле, который линкуется как как объектник или как библиотека (в том числе динамически подгружаемая, в Windows это .dll, в UNIX-системах - shared object, .so). Важно отметить, что #include является свойством языка.

LoadLibrary - это функция одной конкретной операционной системы с семейством компиляторов для подгрузки динамически подгружаемой библиотеки. В Linux её смысловым аналогом является dlopen.

Так что вопрос поставлен некорректно, ведь это разные вещи.

[AnT]

Ternick, Вы не получите доступа к функции, сделав #include. #include лишь даст вам объявление функции, но не прилинкует библиотеку к вашей программе и не загрузит ее. Собственно линковку библиотеки делает линкер, а загрузку - загрузчик. Вот эти два этапа и можно заменить на ручную загрузку через LoadLibrary. #include здесь совершенно сбоку припеку.

[Евгений Шатунов]

Ternick , выбранное решение не отвечает на твой вопрос. Тебя неправильно поняли как тут в комментариях, так и anikavoi .
Решением твоего вопроса является ответ Владимир Коротенко .
Ну и мой ответ тоже стоит внимательно рассмотреть.

[shurshur]

Евгений Шатунов, ну как бы я догадывался, что автор имеет в виду не то, что спросил, но именно поэтому важно было дать ему понимание. И в рамках сформулированного вопроса ответ правильный.

Answer 1

[Евгений Шатунов]

Вопрос, на самом деле, заключается не в выборе межу LoadLibrary и #include, а в выборе между явным и неявным связыванием.

При неявном связывании компоновщик добавляет в PE-секцию импорта дополнительный блок импорта конкретно указанной библиотеки. Этот блок обрабатывается загрузчиком PE в момент подготовки к запуску процесса. Эта информация тебе уже должна быть знакома. К моменту передачи управления в точку входа процесса все неявно связанные библиотеки уже загружены и готовы к работе. Код процесса не нуждается в явном управлении загрузкой таких библиотек.

Явное связывание выполняется полностью кодом процесса, для чего и применяется набор функций для работы с библиотеками. Явное связывание - это большая рутина. Но иногда без этой рутины никак.
Поиск динамических библиотек при работе LoadLibrary[?] осуществляется в соответствии с определенным порядком. При этом, путями для поиска динамических библиотек можно управлять в ручном режиме, добавляя новые или замещая имеющиеся пути поиска.

Директива препроцессора #include[?] лишь косвенно относится к вопросу. На самом деле к вопросу относится директива #pragma comment( lib )[?].
Прагма работает только для cl - компилятора от Microsoft. Подключаемая таким образом статическая библиотека должна находиться в перечисленных Library Path, в настройках сборки проекта. Эта прагма является альтернативой прямого указания статической библиотеки в настройках сборки проекта.
Эту директиву любят использовать в сторонних заголовках, код для которых поставляется только в бинарном виде, в статических или динамических библиотеках. Вместе с динамической библиотекой такого решения поставляется и библиотека статическая, в которой находятся инструкции для неявного связывания с динамической библиотекой. Результатом работы #pragma comment( lib ) с такой статической библиотекой будет неявное связывание твоего кода с указанной динамической библиотекой.

Размер PE ощутимо растет при компоновке из статических библиотек.
Явное и неявное связывание слабо влияют на размер PE, но явное связывание усложняет жизнь разработчика, т.к. поддерживать загрузку интерфейса библиотеки разработчику придется самому.

Answer 2

[Владимир Коротенко]

Насколько я понимаю.
В include описывается библиотека, она может быть статической линковки, так и динамической.
В случае динамической линковки компилятор берет на себя все ваши вызовы loadLibrary, getProcAddress и прочее.

1) Откуда берёт библиотеки LoadLibrary ?

Папка приложения, Системные пути (PATH), knowdlls, полный путь до библиотеки

2) Проверяет ли LoadLibrary подпись библиотеки, если берёт её из системных путей ?
да,
https://msrc-blog.microsoft.com/2014/05/13/load-li...

3) Уменьшится ли размер исполняемого файла если использовать только LoadLibrary, без #include ? {Один не в счёт, надо же как-то брать HMODULE, WINAPI и прочие штуки ...}
Линкуйте библиотеки динамически, размер уменьшится, LoadLibrary ни как не влияет.

4) Что лучше использовать #include или LoadLibrary ?
5) Если библиотека существует и существует метод к которому я хочу обратится, может ли появиться ошибка ?

Понимание что они такие жирные
https://rsdn.org/article/cpp/crt.xml
Как загружается PE файл
https://rsdn.org/article/baseserv/peloader.xml

Answer 3

[anikavoi]

#include - директива предпроцессора компилятора, она "срабатывает" когда вы компилируете свой исходный код.
LoadLibrary - это функция api windows, которая подгружает DLL. Соответственно "срабатывает" когда уже откомпилированный экзешник запущен. DLL - это уже откомпилированная библиотека - она должна лежать где-то по PATH.
2) Насколько я знаю - нет (что там в 8,10,2016 - хз, я уже давно на линуксе)
3) вообще не понял, извините
4) Еще раз - #include - это не "библиотека", хотя конечно в нее можно запузырить весь код, но imho лучше так не делать. В инклюдах должны жить ОБЪЯВЛЕНИЯ, а сам код в .cpp
5) опять не понял.