Должен ли я добавить источник библиотек вместо ссылок на них?

Я относительно новичок в C ++, поэтому я не уверен, как лучше всего обрабатывать небольшие зависимости (например, язык сценариев или анализатор JSON / YAML / XML).

Должен ли я создавать отдельные проекты и связывать их как статическую библиотеку, или есть недостатки в том, чтобы просто помещать файлы .h / .cpp в мой основной проект?

Последнее кажется намного проще, потому что я потратил несколько часов на работу с несовместимыми библиотеками (разные настройки компилятора при сборке библиотеки), но я не хочу начинать с изучения C ++ неправильным способом.

Если желательно хранить их как отдельные библиотеки, как лучше синхронизировать флаги компиляции, чтобы файлы .lib / .a успешно ссылались на мое приложение?

(В настоящее время я работаю с MSVC 2015, но цель состоит в том, чтобы скомпилировать на Mac OS X и iOS с использованием XCode / clang, так что мне приходится иметь дело как минимум с 3 различными типами библиотек (Win x86, Mac x64, ARM) )

TLDR;

Вы должны добавить источник? ДА
Должен ли Х добавить источник? ЗАВИСИТ

Вот почему ...

В свое время время компиляции было проблемой даже для небольших проектов. Компиляция ваших исходных кодов и никогда не беспокоиться о кэшировании результатов компилятора определенно понравились некоторым Это один момент для библиотек, не имеющих отношения к вам.

Другим важным является версионирование. Вам действительно нужно создавать версии каждой библиотеки отдельно? Запустить тесты против каждого? Распределить это среди многих членов команды? Библиотеки - это здорово, если вы делаете, и их удобно перемещать, но опять же, кажется, вам это тоже не важно.

И последнее замечание: это дополнительные накладные расходы, и удаление исходных файлов проще в вашем случае, что дает очень сильную точку для удаления исходных текстов, а не использования библиотек. Как вы заметили, как только вы сделаете одно изменение настроек компилятора, вам придется преследовать все зависимости в противном случае.

Я знаю все это из опыта:

Для проектов Swift я определенно использую фреймворки (библиотеки) и ссылаюсь на них, так как это легко настроить с помощью Xcode. Мне также очень нужны версии, тесты и развязка, вот почему.

Для проектов Mono (C #), для Unity, я начал с модного подхода: разбить проект на библиотеки, скомпилировать и протестировать каждый из них, и это было здорово ... но как только я поместил библиотеки в Unity, возникли всевозможные проблемы от взломанной версии Mono Unity, до просто иногда иного поведения, которое проявляется в коде при смене платформы. Отсутствие единой IDE для управления всеми библиотеками было настоящей проблемой, поэтому размещение всего исходного кода в Unity стало огромным выигрышем для производительности.

Наконец, наиболее актуальный для вас проект игры на C ++, над которым я работал. Для этой игры были написаны игровой движок, сетевой клиент реального времени, сетевой HTTP-клиент, AI и хранилище постоянных данных, только на стороне клиента. Что я выбрал? CLion + Библиотеки. Даже при том, что я использовал библиотеки, я не чувствовал, что я был. Все источники были в проекте CLion IDE, и, составив CMakeLists, я смог запустить все сборки и связать их за один раз.

В заключение я бы сказал, что использование библиотек - это решение, ориентированное на будущее, но также и преждевременная оптимизация, если в этом нет необходимости. Насколько я могу судить по вашей ситуации, переключение с MSVC на Xcode будет проблематичным, если у вас будет многоцелевая сборка. Поэтому просто вставьте его и сохраняйте как можно большую изоляцию, когда вам может понадобиться использовать библиотеки.

PS: у меня сейчас похожая дилемма с докером. Должен ли я сочинять? Должен ли я просто бежать на месте? ... и т. д. Также Elixir, так как он позволяет создавать приложения в одном приложении. Должен ли я это делать? Или разделить приложение на так называемые микро-сервисы? ... и т.д. Там нет серебряной пули, всегда измеряйте себя, как YMMV.

Связывание с библиотеками 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 ++».

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

Я бы сказал, да, пока это проще. Есть довольно много преимуществ:

1. Это приведет к более быстрому и лучшему коду, особенно если вы включите Оптимизацию времени соединения.

2. Ваша IDE понравится больше, например, она (надеюсь) позволит вам перейти к реализации (.cpp) библиотечного кода, а не только к интерфейсу (.h), что чрезвычайно полезно при работе с плохо документированным кодом (т.е. большая часть кода).

3. Он часто позволяет вам добавить зависимость в виде подмодуля git, что является немного хакерским, но на самом деле довольно хорошим способом иметь зависимости (во всяком случае, для C ++, в котором практически нет нормальных систем сборки). Это позволяет легко обновлять библиотеку и тестировать разные версии.

4. Вам не нужно беспокоиться о зависимости, компилируемой с MSVC ++ 2013, когда вы используете 2017 год, например. Или общий против статического MSVCRT.

5. Вы можете легко построить в режиме отладки и войти в библиотеку.

Единственная причина, я думаю, вы бы не захотите этого делать, - это если библиотека большая и имеет сложную систему сборки, которую вы не хотите копировать в своей, например, Boost или LLVM. Но для простых библиотек в действительности нет недостатка.

В качестве примера я использую libusb в нескольких проектах, и мне нужно поддерживать Windows. libusb использует autotools, который является шуткой системы сборки и на самом деле не работает на Windows. Они предоставляют предварительно скомпилированные двоичные файлы, но они построены с MSVC ++ 2013 и не будут работать с 2017 годом. Самым простым решением на сегодняшний день было просто добавить все соответствующие файлы .c и .h в мой проект.