Связывание с библиотеками C ++ требует больших хлопот, и для правильной работы требуется много знаний и усилий. Это может быть пугающим для учеников C ++.
Часто авторы / сопровождающие конкретной библиотеки C ++ будут иметь это в виду и будут рекомендовать так или иначе.
Другими словами, если авторы / сопровождающие намереваются включить библиотеку в заголовки (только * .h и .hpp) или включить по источнику ( .h * или .c ), это было бы ясно сказано в файле readme. или документация.
Библиотеки, разработанные и поддерживаемые для кроссплатформенности (и совместимые с несколькими поставщиками и средами компиляторов C ++), часто имеют систему make-файлов или систему конфигурации сборки (такую как CMake). Эти системы используются для создания оболочек заголовков, сглаживающих различия в платформах, и для создания сценариев, которые будут вызывать компилятор и компоновщик исходных файлов, используя правильные параметры командной строки и в правильной последовательности. В зависимости от платформы и конфигурации, эти системы сборки могут включать или исключать определенные заголовки или исходные файлы, или они могут определять или отменять определенные символы препроцессора.
Возможно пойти против рекомендации авторов / сопровождающих, но это всегда требует значительных усилий по переносу. Объем работы, необходимый для этого процесса переноса, может быть сопоставим с переносом в другую среду C ++.
Поскольку Visual C ++ использует свою собственную систему сборки, основанную на файле описания проекта (частично на основе XML), она совершенно не похожа на систему сборки на основе сценариев, используемую в Linux. Подход, используемый CMake, заключается в том, что CMake принимает параметры конфигурации, а затем генерирует всю структуру проекта Visual C ++ с параметрами конфигурации, включенными в файлы * .vcxproj.
Если при соединении C ++ с Visual C ++ возникают проблемы, параметры сборки в файлах * .vcxproj можно изменить с помощью графического интерфейса Visual Studio (используя диалоговое окно страниц свойств проекта). Это предполагает, что вы полностью понимаете смысл и последствия десятка важных настроек компиляции и связывания C ++.
Теперь самое глупое использование Visual C ++: если вы используете дюжину различных сторонних библиотек, изменение настроек сборки для всех них означает переход в каждый файл * .vcxproj и повторение одного и того же изменения в графическом интерфейсе для дюжины раз. Это хлопотно, но это можно сделать, если вы знаете, как это сделать правильно.
Большинство учеников Visual C ++ изучают эти параметры трудным путем, наблюдая за ошибками компилятора и компоновщика Visual C ++, определяемыми их кодом ошибки. Например, можно посмотреть LNK2005 с поверхностным значением «Символ символа был определен более одного раза», но с пониманием, что дублированное определение не возникает из-за неосторожной ошибки программирования, вместо этого это могло произойти из-за некоторого конфликты или неправильное применение параметров компиляции и компоновки.
Чтобы дать более конкретный и полезный ответ на вашу ситуацию, вам нужно знать названия библиотек, которые вы собираетесь использовать, а также ошибки компоновки или другие трудности, с которыми вы сталкиваетесь. Существующие ответы на эти вопросы вы можете найти на форумах соответствующей библиотеки. Эти вопросы, как правило, помечены как «проблемы со связями», «окна» и «визуальный C ++».
Руководство для начинающих экспертов по этому вопросу возможно, но оно будет зависеть от проекта. Различные предпочтения, выбранные различными проектами, потребуют полной переписки руководства.