.lib, связывающий другие .libs

Question

В настоящее время моя Visual Studio в основном генерирует Engine.dll и Game.exe

Engine.dll ссылается на некоторые другие базовые библиотеки, такие как: d3dx9d.lib ComCtl32.lib WinMM.lib WSock32.lib и т. Д.

Я также хотел попробовать создать Engine.lib, но теперь я получаю несколько действительно хороших предупреждений: символ x уже определен.Эти библиотеки определяют одинаковые символы.

Так что я где-то читал, что вместо этого я должен заставить своего пользователя (Game.exe) ссылаться на библиотеки.Но я думаю, что это очень неудобно, особенно если у меня много игр, и я решил добавить еще одну библиотеку в свой движок.Это просто обслуживание чего-то такого простого.

Должен ли я придерживаться .dll, или есть какой-то способ исправить эту красоту?

Большое спасибо,

Antoon

Answer 1

Вы должны решить, хотите ли вы DLL или статическую библиотеку ссылок.Преимущество DLL в том, что время сборки может быть быстрее, если вы вносите локальные изменения.Преимущество .lib заключается в том, что в итоге у вас будет только один развертываемый файл.

Привязка к нему (статический .lib или импорт .lib библиотеки DLL) в противном случае происходит автоматически.Вы хотите убедиться, что библиотека создается в первую очередь, не можете связать .exe без него.Щелкните правой кнопкой мыши по проекту exe в окне Solution Explorer, Project Dependencies, отметьте галочкой проект библиотеки.Это автоматически добавляет .lib к дополнительным зависимостям проекта exe.

Использование комментария #pragma (lib, "engine.lib") в заголовочном файле движка - это еще один способ.Повторите эти действия для других зависимостей, таких как библиотеки импорта ОС.Правильный путь к библиотеке - элемент // todo.

Answer 2

Вы создали другое пространство имен, чтобы избежать конфликтов имен?

РЕДАКТИРОВАТЬ - кажется, что существует некоторая путаница относительно того, что вы спрашиваете, потому что вы задаете пару вопросов.

Для меня это звучит так, будто вы хотите попытаться реализовать собственный класс Engine. Однако у вас есть проблемы с именами. Сейчас я рассматриваю это как архитектурный вопрос. Если вы напишите свою игру в интерфейс, то проблема исчезнет. Например, если ваш Engine использует разные алгоритмы, то, если вы написали EngineInterface, который реализовали текущий Engine и YourEngine, то вы могли бы легко использовать стратегию для переключения между различными реализациями на лету. Это хорошо, потому что вы сможете увидеть различия в игре, если подключите настройки в приложение.

Answer 3

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

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