Является ли включение исходных файлов C ++ одобренным методом?

Question

У меня есть большой файл C ++ (SS.cpp), который я решил разделить на более мелкие файлы, чтобы я мог перемещаться по нему без необходимости аспирина. Итак, я создал

SS_main.cpp
SS_screen.cpp
SS_disk.cpp
SS_web.cpp
SS_functions.cpp

и вставил в них все функции из исходного файла SS.cpp.

И, наконец, я включил их в исходный файл:

#include "SS_main.cpp"
#include "SS_screen.cpp" 
#include "SS_disk.cpp" 
#include "SS_web.cpp"
#include "SS_functions.cpp"

Эта ситуация сохраняется уже несколько месяцев, и вот проблемы, которые у меня были:

• Поиск по всему решению (Shift-Ctrl-F в VS) не выполняет поиск во включенных файлах, поскольку они не указаны в качестве исходных файлов.

• Мне пришлось вручную указать их для включения в Subversion.

Считаете ли вы, что включение исходных файлов в другие источники является приемлемым обходным решением, когда файлы становятся действительно большими? Я должен сказать, что разделение реализованного класса на более мелкие классы здесь не вариант.

Answer 1

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

Вы должны просто добавить все эти исходные файлы в ваш проект вместо #include их. Нет ничего плохого в том, чтобы разбить большой класс на несколько файлов реализации, но просто добавьте их в свой проект, включая такие, которые не имеют особого смысла.

- Кроме того, в качестве FYI вы можете добавлять файлы в свои проекты, а затем указывать компилятору игнорировать их. Таким образом, они все еще доступны для поиска. Для этого добавьте файл в проект, затем щелкните его правой кнопкой мыши и перейдите в «Свойства» и в разделе «Общие» установите «Исключить из сборки» в значение «Да».

Answer 2

Не включайте файлы cpp в другие файлы. Вам не нужно определять каждую функцию класса в одном файле, вы можете распределить их по нескольким файлам. Просто добавьте их по отдельности в проект, и он скомпилирует их все по отдельности.

Answer 3

Вы не включаете файлы реализации (.cpp). Создайте заголовочные файлы для этих файлов реализации, содержащие объявления функций / классов, и при необходимости включите их.

Answer 4

В действительности вы можете захотеть включить файлы CPP. Здесь есть несколько вопросов о Unity Builds , в которых обсуждается именно эта тема.

Answer 5

Что меня беспокоит в этом вопросе, так это контекст. Был создан большой файл cpp, достаточно большой, чтобы можно было подумать о том, чтобы разбить его на более мелкие и более управляемые файлы. Предлагаемое разделение:
SS_main.cpp
SS_screen.cpp
SS_disk.cpp
SS_web.cpp
SS_functions.cpp

Кажется, это указывает на то, что существуют отдельные функциональные единицы с точки зрения спецификации и дизайна. Мы можем только догадываться о связи между этими единицами кода.

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

Мы проводим рефакторинг здесь.

Недопустимо использовать включенные файлы cpp в этом контексте, так как это не дает никаких преимуществ. Единственный раз, когда я сталкиваюсь с включенными файлами cpp, это когда один из них включен для предоставления кода для кода отладки, и пример - для компиляции не встроенных версий функций. Это помогает в пошаговом выполнении кода в отладчике.

Answer 6

Вам необходимо узнать о Отдельной компиляции , связывании и о том, для чего нужны заголовочные файлы .

Вам необходимо создать заголовочный файл для каждого из этих модулей (кроме, возможно, main.cpp). Заголовочный файл будет содержать декларативные части каждого исходного файла .cpp, а сами файлы .cpp будут содержать инстантивные части. Каждый блок может быть отдельно скомпилирован и связан. Например:

main.cpp

#include "function.h"

int main()
{
    func1() ;
}

---

function.h

#if !defined FUNCTION_H
#define FUNCTION_H

extern void func1() ;

#endif

---

function.cpp

void func1()
{
    // do stuff
}

---

Затем function.cpp и main.cpp компилируются отдельно (добавляя их в исходные тексты проекта), а затем связываются. Заголовочный файл необходим для того, чтобы компилятор узнал об интерфейсе к func1 (), не видя полного определения. Заголовок должен быть добавлен в заголовки проекта, после чего вы обнаружите, что исходный браузер, автозаполнение и т. Д. Работают правильно.