Rozszerzenie pliku kodu C ++? .cc vs .cpp [zamknięte]

Widziałem kod C ++ zapisany jako pliki .cci .cpp. Czy jest jakaś różnica między nimi?

Przewodnik po stylu Google wydaje się sugerować .cc, ale nie zawiera wyjaśnień.

Zajmuję się głównie programami w systemach Linux.

Na koniec dnia nie ma to znaczenia, ponieważ kompilatory C ++ radzą sobie z plikami w dowolnym formacie. Jeśli to poważny problem w zespole, rzuć monetą i przejdź do właściwej pracy.

GNU GCC rozpoznaje wszystkie z poniższych postaci plików C ++ i C ++ użyje kompilacja niezależnie od tego, czy podniesienie go przez gcc lub g ++: .C, .cc, .cpp, .CPP, .c++, .cp, lub .cxx.

Uwaga .C- w GCC sprawa ma znaczenie, .cjest to plik C, podczas gdy .Cjest to plik C ++ (jeśli pozwolisz kompilatorowi zdecydować, co to jest kompilacja).

GCC obsługuje także inne sufiksy wskazujące na specjalną obsługę, na przykład .iiplik zostanie skompilowany jako C ++, ale nie wstępnie przetworzony (przeznaczony dla osobno wstępnie przetworzonego kodu). Wszystkie rozpoznane sufiksy są wyszczególnione na gcc.gnu.org

Świetna rada, której użyć dla makefile i innych narzędzi, biorąc pod uwagę narzędzia inne niż kompilator przy podejmowaniu decyzji, które rozszerzenie do użycia jest świetnym podejściem, aby pomóc znaleźć odpowiedź, która będzie dla Ciebie odpowiednia.

Chciałem tylko dodać następujące informacje, aby pomóc w znalezieniu niektórych informacji .ccvs. .cppOto rozszerzenia w podziale na różne środowiska (z książki „C ++ Primer Plus”):

Unix zastosowania: .C, .cc, .cxx,.c

GNU C ++ zastosowania: .C, .cc, .cxx, .cpp,.c++

Cyfrowy Mars zastosowania: .cpp,.cxx

Borland C ++ używa: .cpp

Watcom używa: .cpp

Microsoft Visual C ++ zastosowania: .cpp, .cxx,.cc

Metrowerks CodeWarrior zastosowania: .cpp, .cp, .cc, .cxx,.c++

Różne środowiska obsługują różne rozszerzenia. Ja też szukałem odpowiedzi na to pytanie i znalazłem ten post. Opierając się na tym poście, myślę, że mogę pójść za .hppi .cppdla ułatwienia rozpoznawania różnych platform / narzędzi.

.cppjest zalecane rozszerzenie dla C ++, o ile wiem. Niektóre osoby zalecają nawet używanie .hppnagłówków C ++, aby odróżnić je od C.

Mimo że kompilator nie dba o to, co robisz, jest to osobiste preferencje.

Osobiście używam .ccrozszerzenia do plików implementacyjnych, .hhdo nagłówków i .inldo wbudowanych / szablonów.

Jak powiedziano wcześniej, jest to głównie kwestia gustu.

Z tego, co widziałem , .ccwydaje się być bardziej „ zorientowany na projekty open source ”, jak to jest zalecane w niektórych świetnych stylach kodowania oprogramowania open source, podczas gdy. cppwydaje się bardziej oknoowy.

--- EDYTOWAĆ

Jak wspomniano, jest to „z tego, co widziałem” , może być źle. Po prostu wykorzystałem wszystkie projekty Windows, nad którymi pracowałem .cpp, i wiele projektów typu open source (głównie na systemach uniksowych) .cc.

Przykłady stylów kodowania przy użyciu .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

Inne używane rozszerzenia plików to .cxxi .C(wielkie C). Wierzę, że .Cpierwotnie używał Bjarne Stroustrup . .cppto nazwa preprocesora C, więc niefortunnie jest, że był on również używany w C ++.

Inną opcją jest miejsce, .cxxgdzie xma być plus obrócony o 45 °.

Obsługiwane są systemy Windows, Mac i Linux, .c++więc powinniśmy z tego skorzystać.

Kilka osób mówi, że .ccnic nie znaczy? Może. C ++ zaczął życie jako „C with Classes”.

Prawda, że .cc a .cpptakże nazwy poleceń w większości systemów uniksowych (odpowiednio kompilator c i preprocesor c).

Używam .cppwyłącznie, ale zacząłem na Windowsie. .ccjest bardziej konwencją uniksową, chociaż coraz mniej ją tam widzę. GNU make ma reguły, .cppwięc jest to prawdopodobnie preferowane, będzie domyślnie działać zarówno w systemie Windows, jak i we wszystkich innych. Z drugiej strony nowoczesne C ++ w ogóle nie używa rozszerzenia dla nagłówków, naprawdę tego nie lubię. Wszystkie moje projekty używają .hplików nagłówkowych i obsługują zarówno C, jak i C ++ w jak największym stopniu poprzez extern "C"i testowanie __cplusplus.

Postępuj zgodnie z konwencją używaną przez projekt / zespół.

Osobiście nigdy nie widziałem .cc w żadnym projekcie, nad którym pracowałem, ale pod względem technicznym kompilatora to nie obchodzi.

Dbają o to programiści pracujący na Twoim źródle, więc moją podstawową zasadą jest dostosowanie się do tego, co czuje twój zespół. Jeśli twój „zespół” jest społecznością typu open source, wybierz coś bardzo powszechnego, z czego .cppwydaje się być ulubionym.

Podobnie jak w przypadku większości konwencji stylu, ważne są tylko dwie rzeczy:

1. Zachowaj spójność w zakresie korzystania, tam gdzie to możliwe.
2. Nie projektuj niczego, co zależy od zastosowanego konkretnego wyboru.

Może się to wydawać sprzeczne, ale każdy z nich ma wartość z własnych powodów.

.Ci .ccwydają się być standardem dla (kilku) zorientowanych na Uniksa programów C ++, które widziałem. Zawsze używałem .cppsamego siebie, ponieważ naprawdę pracuję tylko w systemie Windows, a to jest standard tam od zawsze.

Polecam .cpposobiście, ponieważ ... oznacza „C Plus Plus”. Oczywiście bardzo ważne jest, aby rozszerzenia plików były akronimami, ale jeśli to uzasadnienie okaże się niewystarczająco przekonujące, innymi ważnymi rzeczami są niestosowanie klawisza Shift (który wyklucza .Ci .c++) oraz unikanie metaznaków wyrażeń regularnych tam, gdzie to możliwe (co wyklucza .c++- niestety nie da się tego uniknąć ..).

To nie wyklucza .cc, więc nawet jeśli tak naprawdę nic nie oznacza (czy robi to?), To prawdopodobnie jest dobrym wyborem dla kodu zorientowanego na Linuksa.

Używam .C i .h odpowiednio dla źródła i nagłówka. Jedną fajną rzeczą przy tym wyborze jest to, że w wierszu poleceń można łatwo *.[Ch]wybrać wszystkie pliki kodu. Używanie .Cmoże być problemem w systemach plików bez rozróżniania wielkości liter, ale jeśli masz foo.ci znajduje się foo.Cw tym samym katalogu, zasługujesz na to, co dostajesz :)

Rozszerzenie .cc jest niezbędne do korzystania z reguł niejawnych w plikach makefiles. Przejrzyj te linki, aby lepiej zrozumieć pliki makefile, ale spójrz głównie na drugi, ponieważ wyraźnie mówi o przydatności rozszerzenia .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

Właśnie się o tym dowiedziałem.

Nie ma znaczenia, którego rozszerzenia użyjesz. Wybierz cokolwiek bardziej lubisz, zachowaj spójność z nazywaniem. Jedyny wyjątek, o którym wiem z tą konwencją nazewnictwa, to to, że nie mogłem WinDDK(lub jest to WDKteraz?) Kompilować .ccplików. W systemie Linux nie stanowi to jednak problemu.

Zaczynam nowy projekt w C ++ i zacząłem szukać najnowszych w stylu C ++. Skończyło się tutaj na nazwach plików i pomyślałem, że podzielę się tym, jak wymyśliłem swój wybór. Tutaj idzie:

Stroustrup postrzega to bardziej jako kwestię biznesową niż techniczną .

Postępując zgodnie z jego radą, sprawdźmy, czego oczekują łańcuchy narzędzi.

W systemach UNIX / Linux możesz interpretować następujące domyślne reguły tworzenia GNU jako faworyzujące przyrostek nazw plików .cc, ponieważ reguły .cpp i .C to tylko aliasy:

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

(Uwaga: nie ma domyślnego aliasu COMPILE.cxx)

Więc jeśli celujesz w UNIX / Linux, zarówno .cc, jak i .cpp są bardzo dobrymi opcjami.

Podczas celowania w system Windows szukasz problemów z .C, ponieważ jego system plików nie rozróżnia wielkości liter. I może być ważne, aby pamiętać, że Visual Studio preferuje sufiks .cpp

Podczas celowania w macOS należy pamiętać, że Xcode woli .cpp / .hpp (właśnie zaznaczone na Xcode 10.1). Zawsze możesz zmienić szablon nagłówka na .h.

Za to, co jest warte, możesz również oprzeć swoją decyzję na podstawie kodu, który ci się podoba. Google używa .cc a LLVM libc ++ używa .cpp.

Co z plikami nagłówkowymi? Są one kompilowane w kontekście pliku C lub C ++, więc nie ma żadnego kompilatora ani systemu kompilacji, aby odróżnić .h od .hpp. Podświetlanie składni i automatyczne wcięcia przez edytor / IDE mogą jednak stanowić problem, ale rozwiązuje się to poprzez powiązanie wszystkich plików .h z trybem C ++. Jako przykład, moja konfiguracja emacsa w systemie Linux ładuje wszystkie pliki .h w trybie C ++ i edytuje nagłówki C w porządku. Poza tym, mieszając C i C ++, możesz postępować zgodnie z tą radą .

Mój osobisty wniosek : .cpp / .h to ścieżka najmniejszego oporu.

Jak inni pisali przede mną, na końcu jest to, z czego korzysta twój projekt / zespół / firma.

Osobiście nie używam cc rozszerzenia, staram się obniżyć liczbę rozszerzeń i nie zwiększać ich, chyba że istnieje wyraźna wartość (moim zdaniem).

Do tego, co jest tego warte, używam :

c - Tylko czysty kod C, bez klas i struktur z metodami.

cpp - kod C ++

hpp- Kod tylko nagłówki. Implementacje znajdują się w nagłówkach (np. Klasy szablonów)

h- pliki nagłówkowe dla obu C / C ++. Zgadzam się, że można wprowadzić inne rozróżnienie, ale jak napisałem, staram się zmniejszyć liczbę rozszerzeń dla uproszczenia. Przynajmniej z projektów C ++, w których pracowałem, hpliki dla czystego C są rzadsze, dlatego nie chciałem dodawać kolejnego rozszerzenia.