Как объединить компоненты больших проектов на C++?

Question

У меня вопрос о том, как большие проекты на C++ со многими компонентами должны управляться (я думаю, это лучший термин). Для всех целей и задач я начинаю программист. Я понимаю основы компиляции, файлы заголовков и т. Д., Но я никогда не работал над чем-то большим, чем домашнее задание. Итак, давайте возьмем что-то вроде движка игры, в котором есть различные компоненты, такие как менеджер памяти, рендеринг, физическое моделирование и т. Д. Как работать над этими компонентами отдельно, но таким образом, чтобы упростить интеграцию в целом? Например, вы бы сделали отдельный проект визуальной студии для каждой части своей собственной основной? Если у вас есть один большой проект для всего, как бы вы работали над одним компонентом, не имея потенциально другого незавершенного компонента, делающего его неудачным с каждым компилятором? Я чувствую, что мне не хватает какой-то важной концепции. Например, для проектов с несколькими программистами, которым приходится проверять порции на работу ... они захватывают весь код, чтобы они могли скомпилировать, или они создали свой собственный временный проект для работы над своим битом? Оба варианта звучат неправильно. У вас должна быть основная функция для компиляции?

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

Answer 1

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

Попробуйте найти gmake (для linux), чтобы посмотреть, как строить большие проекты. Я предполагаю, что вы используете Microsoft VC++, и в этом случае скомпилированные файлы имеют расширения .obj и библиотеки .lib extensions. У Microsoft есть собственный способ создания библиотек, который намного сложнее, чем использование gmake.

Когда вы смотрите дальше, вы столкнетесь с разделяемыми библиотеками (динамическими библиотеками ссылок на Windows - DLL).

Answer 2

Это не очень большой вопрос для формата переполнения стека. C++ поддерживает языковые возможности для управления большими базами кода, такими как пространства имен, классы и заголовочные файлы. Но ваш вопрос, кажется, предполагает отсутствие перспективы в отношении того, для чего они предназначены, или ограниченное понимание технической основы и процесса внесения кода в программный проект. Это не проблема с C++.

При работе над живым проектом основная проблема связана со сложностью. Или, другими словами, сокращение количества вещей, о которых вы должны думать в любой момент времени. Что это значит, если другой программист работает над пользовательским интерфейсом, в идеале ваш код в физическом движке не должен изменяться, чтобы отражать эти изменения. Таким образом, интерфейсы, для формирования абстракций и скрытия информации, имеют важное значение.

Конечно, я тоже очень зелёный, поэтому я не могу дать никаких реальных твердых советов. Я только упоминаю этот момент, чтобы дать некоторое представление о том, насколько неопределен ваш вопрос. Если я правильно понимаю ваш вопрос, вам может понравиться книга, написанная МакКоннеллом «Code Complete 2».

Answer 3

Крупные проекты разделены на куски. Как правило, вы должны иметь возможность составлять каждую деталь отдельно. Лучшая практика, которую я знаю, - объявить интерфейсы между различными компонентами, минимизируя зависимости как можно ближе к нулю, а затем строя «тестовые» программы, которые являются небольшими и служат двум причинам: протестировать небольшой фрагмент кода,(). структура каталогов, как правило:

yourlib/ 
    lib/ 
    ext-inc/ 
    test/ 
    other dirs/ 
    ... 

Либерал содержит объект вывода библиотеки (.a, .so) доб Пб содержит заголовки внешний код будет использовать (иногда называемый «общественный» или просто «вкл ') В тестовом каталоге обычно есть файл main.c (cpp), и при необходимости может быть еще несколько.

При заказе (svn)/clone (git)/sync (p4)/и т. Д. Вы берете все, но работаете только на своей территории. как только вы закончите, вы объедините/отправьте свои изменения в основную ветку.