Расширение файла кода C ++? .cc против .cpp

GNU GCC распознает все следующие файлы С++ и будет использовать компиляцию С++ независимо от того, вы используете ее через gcc или g++: .C, .cc, .cpp, .cpp, .c++, .cp или .cxx.

Обратите внимание на .C - дело имеет значение в GCC, .C является файлом C, тогда как .C является С++ файлом (если вы разрешите компилятору решить, что он компилирует).

GCC также поддерживает другие суффиксы для указания специальной обработки, например, файл .ii будет скомпилирован как С++, но не предварительно обработан (предназначен для отдельного предварительно обработанного кода). Все признанные суффиксы подробно описаны в gcc.gnu.org

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

Я просто хотел добавить следующее, чтобы помочь с некоторыми .cc vs .cpp информацией, которую я нашел. Ниже приведены расширения, разбитые по разным средам (из книги "C++ Primer Plus"):

Unix использует: .C, .cc, .cxx, .c

GNU C++ использует: .C, .cc, .cxx, .cpp .C++

Digital Mars использует: .cpp, .cxx

Borland C++ использует: .cpp

Watcom использует: .cpp

Microsoft Visual C++ использует: .cpp, .cxx, .cc

Metrowerks CodeWarrior использует: .cpp, .cp, .cc, .cxx .C++

Разные среды поддерживают разные расширения. Я тоже искал, чтобы ответить на этот вопрос и нашел этот пост. Основываясь на этом посте, я думаю, что я мог бы пойти с .hpp и .cpp для простоты кросс-платформенного/кросс-инструментального распознавания.

.cpp является рекомендуемым расширением для С++, насколько мне известно. Некоторые люди даже рекомендуют использовать .hpp для заголовков С++, чтобы отличать их от C.

Хотя компилятору все равно, что вы делаете, это личные предпочтения.

Я лично использую расширение .cc для файлов реализации, .hh для заголовков и .inl для встроенных/шаблонов.

Как говорилось ранее, это в основном вопрос вкуса.

Из того, что я видел, .cc, похоже, больше ориентирован на проекты с открытым исходным кодом, поскольку он рекомендуется в некоторых великолепных стилях кодирования программного обеспечения с открытым исходным кодом, тогда как. cpp кажется более Windowish.

--- EDIT

Как уже упоминалось, это "из того, что я видел", это может быть неправильно. Это просто, что все проекты Windows, над которыми я работал, использовали .cpp, а много проектов с открытым исходным кодом (которые в основном относятся к unix-like) используют .cc.

Примеры стилей кодирования с использованием .cc:

• Google: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
• ICL: http://www.doc.ic.ac.uk/lab/cplus/c++.rules/chap4.html#sect2

Другие используемые расширения файлов включают .cxx и .C (капитал C). Я считаю, что Бьярне Страуступ первоначально использовал .C. .cpp - это имя препроцессора C, поэтому ему не повезло, что он также использовался для С++.

Просто следуйте за соглашением, используемым проектом/командой.

Другим вариантом является .cxx, где предполагается, что x является плюсом, повернутым на 45 °.

Windows, Mac и Linux поддерживают .c++, поэтому мы должны просто использовать это.

Несколько человек, говорящих .cc, ничего не стоят? Возможно. С++ начал жизнь как "C с классами".

Верно, что .cc и .cpp также являются именами команд в большинстве систем Unix (c компилятор и c препроцессор соответственно).

Я использую .cpp исключительно, но я начал работать в Windows. .cc - скорее соглашение Unix, хотя я вижу его все меньше и меньше. У GNU make есть правила для .cpp, поэтому, вероятно, предпочтительнее, он будет работать по умолчанию как в Windows, так и во всем остальном. С другой стороны, современный С++ не использует никакого расширения для заголовков, мне это действительно не нравится. Все мои проекты используют .h для файлов заголовков, и они максимально поддерживают как C, так и С++ с помощью extern "C" и тестирования __cplusplus.

Я никогда не видел .cc в любом проекте, над которым я работал, но по всем техническим требованиям компилятору все равно.

Кто будет заботиться о том, чтобы разработчики работали над вашим источником, поэтому мое эмпирическое правило - это то, что вам нравится в вашей команде. Если ваша "команда" - сообщество с открытым исходным кодом, переходите к чему-то очень распространенному, из которых .cpp кажется фаворитом.

Не важно, какое из этих расширений вы будете использовать. Выберите то, что вам больше нравится, просто согласитесь с именованием. Единственное исключение, о котором я знаю в этом соглашении об именах, заключается в том, что я не мог сделать WinDDK (или это WDK сейчас?) Для компиляции файлов .cc. На Linux это вряд ли проблема.

Я использую .C и .h для источника и заголовка, соответственно. Одна хорошая вещь с этим выбором заключается в том, что в командной строке его легко использовать *.[Ch] для выбора всех файлов кода. Использование .C может быть проблемой для нечувствительных к регистру файловых систем, но если у вас есть foo.c и foo.c в том же каталоге, вы все равно заслуживаете того, что получите:)

Как и в большинстве конвенций стиля, есть только две вещи:

• Будьте в курсе того, что вы используете, где это возможно.
• Не создавайте ничего, что зависит от конкретного выбора.

Возможно, это противоречит, но каждый из них имеет ценность по своим причинам.

.C и .cc кажутся стандартными для (нескольких) Unix-ориентированных программ на С++, которые я видел. Я всегда использовал .cpp сам, поскольку я действительно работаю только на Windows, и это был стандарт там, так как навсегда.

Я рекомендую .cpp лично, потому что... это означает "C Plus Plus". Разумеется, жизненно важно, чтобы расширения файлов были аббревиатурами, но если это обоснование окажется недостаточно убедительным, другие важные вещи - это не использование ключа сдвига (который исключает .C и .c++) и избегает метасимволов регулярного выражения, где это возможно (что исключает .c++ - к сожалению, вы действительно не можете избежать ., конечно.).

Это не исключает .cc, поэтому, хотя это действительно не означает ничего (или делает это?), это, вероятно, хороший выбор для Linux-ориентированного кода.

Расширение .cc необходимо для использования неявных правил в make файлах. Просмотрите эти ссылки, чтобы лучше понять make файлы, но посмотрите в основном второй, так как он ясно говорит о полезности расширения .cc:

ftp://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_2.html

https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_10.html

Я только что узнал об этом сейчас.

cpp = c plus plus, и поэтому я предпочитаю, что означает cc или cxx?

Я начинаю новый проект C++ и начинаю искать последние в стиле C++. Я попал сюда по поводу именования файлов и подумал, что поделюсь своим мнением. Вот оно:

Страуструп рассматривает это скорее как деловое соображение, чем как техническое.

Следуя его совету, давайте проверим, чего ожидают цепочки инструментов.

Для UNIX/Linux вы можете интерпретировать следующие стандартные правила GNU make как предпочтение суффиксу имени файла .cc, так как правила .cpp и .C являются просто псевдонимами:

$ make -p | egrep COMPILE[^=]+=
COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
COMPILE.cpp = $(COMPILE.cc)
COMPILE.C = $(COMPILE.cc)

(Примечание: псевдоним COMPILE.cxx по умолчанию отсутствует)

Так что, если вы нацелены на UNIX/Linux, и .cc, и .cpp - очень хорошие варианты.

Ориентируясь на Windows, вы ищете проблемы с .C, так как ее файловая система не учитывает регистр. И вам может быть важно отметить, что Visual Studio предпочитает суффикс .cpp

При нацеливании на macOS обратите внимание, что Xcode предпочитает .cpp/.hpp (только что проверено на Xcode 10.1). Вы всегда можете изменить шаблон заголовка, чтобы использовать .h.

Для чего бы это ни стоило, вы также можете основывать свое решение на кодовых базах, которые вам нравятся. Google использует .cc, а LLVM lib C++ использует, например,.cpp.

Как насчет заголовочных файлов? Они скомпилированы в контексте файла C или C++, поэтому компилятору или системе сборки не нужно отличать .h от .hpp. Однако может возникнуть проблема с подсветкой синтаксиса и автоматическим отступом вашего редактора /IDE, но это можно исправить, связав все файлы .h с режимом C++. Например, моя конфигурация emacs в Linux загружает все файлы .h в режиме C++ и прекрасно редактирует заголовки C. Кроме того, при смешивании C и C++ вы можете следовать этому совету.

Мой личный вывод: .cpp/.h - путь наименьшего сопротивления.