Какова наилучшая практика между неявным связыванием и явным связыванием DLL

Question

Я видел, что существует много разных причин для ссылки .DLL неявно и явно. В настоящее время я использую Visual Studio 2015 и C++ с SFML.

Неявный: -Хорошая сторона: У вас есть доступ к заголовку .DLL (.h) и известно о функции, которую она содержит. Легче связать и использовать. Меньше подвержены ошибкам. Кажется, что это самая распространенная практика.

-Подробная сторона: Абсолютно нужен файл .lib, .h и .dll для связи. Возьмите больше места на диске из-за большего количества файлов.

Явный: -Хорошая сторона: Снимите дисковое пространство из-за необходимости использования только DLL.

-Наконечная сторона: Устранить ошибку из-за возможности использования функции, которую может иметь dll, а также путем ее правильной загрузки. Невозможно узнать, какую функцию хранит dll, поскольку у вас нет заголовка.

1: Я слышал, что ссылка явно является плохой практикой. Это верно?

2: Должен ли я сосредоточиться в основном на неявной увязке?

3: Очевидно, что мои знания в DLL минимальны, есть ли еще хорошая и плохая сторона, я не видел о неявных и явных способах «связывать dll?

4: Поскольку я планирую сделать игру, рекомендуется ли разместить спрайт-лист в dll для загрузки текстуры один раз указателем?

Answer 1

Вы можете удалить пункт «взять меньше места на диске». * .lib требуется только на машине разработчика. В установщике в обоих случаях требуется только DLL.

1. Это зависит от варианта использования. Бывают случаи, когда явное связывание (обычно называемое динамической загрузкой) является единственным способом, например, когда эти DLL реализуют пользовательские плагины.

2. Для игры или другого приложения для настольных компьютеров, ориентированного на детей большой аудитории неопытных пользователей, я вообще не рекомендую использовать DLL. Свяжите весь код статически. Мало того, что ваше приложение меньше (компоновщик выкинет любой код из тех библиотек, которые вы не вызываете), это также устранит класс ошибок. Это, безусловно, относится и к библиотеке времени выполнения (msvcrt.dll).

_4. Я бы этого не сделал. Логически, спрайт-лист - это данные, а не код. Вы не должны размещать его в DLL независимо от того, как вы загружаете DLL, статически или динамически. Вместо этого загрузите эти данные из файла. Если вам нужны только эти данные во время загрузки игры или уровня, используйте API ReadFile. Если вы постоянно читаете этот лист спрайтов во время игры, вы можете сопоставить этот полный файл данных с адресным пространством вашего процесса, см. CreateFileMapping и API MapViewOfFile (внутренне, загрузка DLL использует этот метод). Просто остерегайтесь 32-битных приложений.