Почему рекомендуется использовать несколько файлов при создании проекта C++?
Я изучаю С++ и исхожу из GML, который очень похож по синтаксису. Но чего я не понимаю, так это почему рекомендуется разбивать проект на несколько файлов и несколько типов файлов.
Насколько я понимаю, файлы cpp являются фактическим программным кодом, поэтому люди используют несколько файлов, чтобы разбить функции и части программы на отдельные файлы. Файлы заголовков имеют тот же код, что и cpp, но они используются файлами cpp, поэтому это повторяющийся код, на который можно ссылаться в нескольких местах. Это верно?
Для меня это не имеет особого смысла, потому что вы не собираетесь обмениваться файлами для разных сборок, вам все равно придется перекомпилировать, и все файлы будут объединены в двоичный файл (или несколько, если есть dll).
Так что для меня не было бы больше смысла иметь только один большой файл? Вместо того, чтобы иметь файлы заголовков, которые имеют повторяющиеся ссылки на них во многих файлах cpp, просто разместите код файлов заголовков в верхней части одного файла cpp и создайте разделы вниз по файлу, используя области для содержимого того, что было бы много файлов cpp.
Я видел несколько руководств, которые создают небольшие игры, такие как змейка, используя один файл, и они просто создают разделы по мере продвижения вниз. Сначала инициализация переменных, потом еще раздел со всеми функциями и логикой. Затем рендерер, а затем основная функция. Нельзя ли масштабировать это для большого проекта? Это просто для организации, потому что, пока я все еще учусь, я чувствую, что поиск по множеству файлов более запутан, пытаясь отследить, какие файлы ссылаются на какие другие файлы и где что происходит. Если бы все это было в одном файле, вы могли бы просто прокрутить вниз, и любые сделанные ссылки будут относиться к коду, определенному выше.
Это неправильно или просто не принято? Есть ли недостатки?
Если кто-то может пролить некоторое понимание, я был бы признателен.
На работе мы делим код на несколько файлов, что снижает вероятность того, что несколько разработчиков будут работать над одним и тем же файлом (файлами). Кроме того, после компиляции файла его не нужно компилировать снова. Кроме того, с помощью отдельных файлов вы можете показать, что изменено лишь несколько файлов, которые нуждаются в тестировании (это часть опыта FDA).
Similar syntax != Same semantics. Будьте осторожны, чтобы применить то, что вы узнали на одном языке, к другому языку. Просмотр нескольких файлов — хороший способ отделить разные части вашей программы от других частей программы. Таким образом вы гарантируете, что фрагменты кода не смогут без усилий получить доступ друг к другу (это также часть того, почему существуют классы). Если вы поместите весь код в один большой файл, со временем весь код начнет напрямую использовать все остальные части кода, и вы окажетесь в аду сопровождения.
А также разбиение по разным файлам — это только начало. Вы также должны разделить файлы на разные проекты, сначала создайте статические библиотеки, которые можно связать. Это также помогает фрагментам кода оставаться в значительной степени независимыми друг от друга и еще больше сократить время сборки. Кроме того, с вашим кодом в статических библиотеках вы можете связать его с исполняемым файлом модульного теста И с исполняемым файлом конечного продукта отдельно, что опять же помогает при разработке и тестировании больших проектов.
Если бы мой большой проект был одним большим файлом, его компиляция заняла бы около часа. Поскольку мой проект состоит из множества небольших файлов, на компиляцию одного файла и компоновку объектного кода уходит меньше минуты. Увеличение производительности x60, поскольку обычно изменяется только небольшой набор файлов, что требует компиляции только этих нескольких файлов.
Ответы 1
Вы можете использовать один файл, если хотите. Несколько файлов имеют преимущества.
Да, вы меняете местами разные файлы для разных сборок. Или, по крайней мере, некоторые люди делают. Это распространенный метод создания проектов, работающих на нескольких платформах.
Трудно перемещаться по очень большому файлу. Проекты могут иметь 100 000 строк кода или 2 000 000 строк кода, и если вы поместите все в один файл, его будет очень сложно редактировать. Ваш текстовый редактор может работать медленно или даже не сможет загрузить весь файл в память.
Быстрее создавать проект поэтапно. C++ страдает от относительно длительного времени сборки в среднем для типичных проектов. Если у вас есть несколько файлов, вы можете создавать их постепенно. Часто это быстрее, так как вам нужно перекомпилировать только измененные файлы и их зависимости.
Если ваш проект очень большой и вы помещаете все в один файл, возможно, компилятору не хватит памяти при его компиляции.
Вы можете создавать безымянные пространства имен и статические переменные/статические функции, которые нельзя вызывать из других файлов. Это позволяет вам писать код, который является частным для одного файла, и предотвращает случайный вызов его или доступ к переменным из других файлов.
Каждый из нескольких членов команды может работать с разными файлами, и вы не столкнетесь с конфликтами слияния, когда вы оба отправите свои изменения в общий репозиторий. Если вы оба работаете над одним и тем же файлом, у вас больше шансов получить конфликты слияния.
Я чувствую, что это более запутанно искать во многих файлах, пытаясь отследить, какие файлы ссылаются на какие другие файлы и где что-то происходит.
Если у вас есть хороший редактор или IDE, вы можете просто щелкнуть вызов функции или нажать F12 (или другую клавишу), и он перейдет к определению этой функции (или типа).
Это имеет большой смысл. Спасибо!
Мне вспоминается проект C++, над которым я работал, и для компиляции всего проекта потребовался 1 час. К счастью, проект был не одним файлом, поэтому компиляция обычно занимала секунды, а не час.