Visual Studio — Как вы комбинируете компоненты больших проектов C ++?
У меня есть вопрос о том, как большие проекты C ++ со многими компонентами должны управляться (я думаю, это лучший термин). Во всех отношениях я начинающий программист. Я понимаю основы компиляции, заголовочные файлы и т. Д., Но я никогда не работал над чем-то большим, чем домашние задания. Итак, давайте возьмем что-то вроде игрового движка, который имеет различные компоненты, такие как диспетчер памяти, рендеринг, симуляция физики и так далее. Как можно работать с этими компонентами по отдельности, но так, чтобы их было легко интегрировать обратно в целое? Например, вы бы сделали отдельный визуальный студийный проект для каждого произведения со своим основным? Если у вас есть один большой проект для всего, как бы вы работали над одним компонентом без потенциально другого незавершенного компонента, который приводил бы к сбою каждой компиляции? Я чувствую, что мне не хватает какой-то важной концепции. Например, для проектов с несколькими программистами, которые должны извлекать части для работы … они берут весь код, чтобы их можно было скомпилировать, или они настраивают свой собственный временный проект, чтобы работать на них? Оба варианта звучат неправильно. Вы должны иметь основную функцию для компиляции правильно?
Я был бы очень признателен всем, кто обучает меня этой теме, так как я чувствую, что это то, что я должен иметь и просто как-то упустил полностью.
Решение
Когда вы работаете с более крупными программами, обычно имеется один исходный файл с основной программой, а остальные (может быть много исходных файлов) вызываются из основной. Тогда вам нужна стратегия сборки. Вы можете написать файл сценария, который компилирует каждый из ваших исходных файлов, а затем связывает их все вместе. К сожалению, это может привести к длительному времени сборки, поэтому профессиональные программисты используют файлы make, которые перестраивают только те файлы, которые меняются.
В качестве дальнейшего усовершенствования вы можете организовать группы источников в библиотеки и построить библиотеки отдельно, а затем связать их с оставшимися скомпилированными исходными файлами.
Попробуйте поискать gmake (для linux), чтобы узнать, как создавать большие проекты. Я предполагаю, что вы используете Microsoft VC ++, и в этом случае скомпилированные файлы имеют расширения .obj и библиотеки .lib. У Microsoft есть собственный способ создания библиотек, который немного сложнее, чем использование gmake.
Если вы посмотрите дальше, вы столкнетесь с общими библиотеками (библиотеки динамических ссылок в Windows — DLL).
Другие решения
Это не очень хороший вопрос для формата переполнения стека. C ++ поддерживает языковые средства для управления большими базами кода, такими как пространства имен, классы и заголовочные файлы. Но ваш вопрос, по-видимому, предполагает отсутствие перспективы относительно их предназначения или ограниченное понимание технической основы и процесса внесения кода в программный проект. Что не является специфической проблемой C ++.
При работе над живым проектом первостепенное значение имеет сложность. Или, другими словами, сокращение количества вещей, о которых вы должны думать в любой момент времени. Это означает, что если другой пользователь работает над пользовательским интерфейсом, в идеале ваш код в физическом движке не должен изменяться, чтобы отражать эти изменения. Таким образом, интерфейсы для формирования абстракций и сокрытия информации очень важны.
Конечно, я тоже довольно зеленая, поэтому не могу дать какого-либо серьезного совета. Я только упомяну этот момент, чтобы дать некоторую перспективу относительно того, насколько неопределенным является ваш вопрос. Если я правильно понимаю ваш вопрос, вам может понравиться такая книга, как Code Complete 2 от McConnell.
Большие проекты разбиты на куски. Обычно у вас должна быть возможность компилировать каждый фрагмент отдельно. Лучшая практика, которую я знаю, — объявлять интерфейсы между различными компонентами, сводя к минимуму зависимости как можно ближе к нулю, а затем создавать «тестовые» программы, которые являются небольшими и служат двум причинам: протестировать небольшой фрагмент кода, иметь основной ().
Структура каталогов обычно:
yourlib/
lib/
ext-inc/
test/
other dirs/
...
библиотека содержит объект библиотеки вывода (.a, .so)
ext-lib содержит заголовки, которые будет использовать внешний код (иногда называемый ‘public’ или просто ‘inc’)
Тестовый каталог обычно имеет файл main.c (cpp) и может иметь еще несколько при необходимости.
Когда вы извлекаете (svn) / клон (git) / sync (p4) / и т. Д., Вы берете все, но работаете только в своем регионе. После этого вы объединяете / отправляете свои изменения в основную ветку.