Jakie byłyby ograniczenia C ++ w porównaniu z językiem C? [Zamknięte]

Oto zalety języka C ++

• C ++ udostępnia określone funkcje, o które pytają
• Ich kompilator C jest prawie na pewno kompilatorem C ++, więc nie ma wpływu na koszty oprogramowania
• C ++ jest tak samo przenośny jak C
• Kod w C ++ może być tak samo wydajny jak C (lub bardziej lub mniej)

Czy są jakieś konkretne powody i konkretne scenariusze, w których trzeba używać C zamiast C ++?

Odniesienie do tego pytania: Biblioteka generyków w C

Nie jest to duplikat, ponieważ to pytanie dotyczy ograniczeń językowych, a nie tego, czy powinien / nie powinien uczyć się jednego języka ponad drugim.

Post Petera Kirkhama był dla mnie najbardziej pouczający, szczególnie w odniesieniu do kwestii C99, których nie brałem pod uwagę, więc go zaakceptowałem. Dziękujemy wszystkim innym, którzy wzięli udział.

Jest to spowodowane odpowiedzią, której udzieliłem na bieżące pytanie, która dotyczy biblioteki generycznej dla C - pytający wyraźnie stwierdza, że ​​nie chce używać C ++.

C to kompletny język programowania. C nie jest arbitralnym podzbiorem C ++. C nie jest w ogóle podzbiorem C ++.

To jest ważne C:

foo_t* foo = malloc ( sizeof(foo_t) );

Aby skompilować się jako C ++, musisz napisać:

foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );

co już nie jest poprawne w C. (możesz użyć rzutowania w stylu C, w takim przypadku skompilowałoby się w C, ale odrzuca go większość standardów kodowania C ++, a także wielu programistów C; zobacz komentarze "nie rzucaj malloc" w całym Stack Overflow) .

Nie są tym samym językiem, a jeśli masz istniejący projekt w C, nie chcesz przepisać go w innym języku, aby użyć biblioteki. Wolisz używać bibliotek, z którymi możesz się komunikować w języku, w którym pracujesz. (W niektórych przypadkach jest to możliwe dzięki kilku extern "C"funkcjom opakowującym, w zależności od szablonu / wbudowanej biblioteki C ++).

Biorąc pierwszy plik C w projekcie pracuję nad tym, co się dzieje, jeśli tylko zamiana gcc std=c99na g++:

sandiego:$ g++ -g  -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3  -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc  src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier

W sumie 69 wierszy błędów, z których cztery to nieprawidłowe konwersje, ale głównie dla funkcji, które istnieją w C99, ale nie w C ++.

To nie tak, że używam tych funkcji dla zabawy. Przeniesienie go na inny język wymagałoby znacznej pracy.

Tak więc sugerowanie tego jest oczywistym błędem

[a] Kompilator C jest prawie na pewno kompilatorem C ++, więc nie ma wpływu na koszty oprogramowania

Przeniesienie istniejącego kodu C do proceduralnego podzbioru C ++ wiąże się często ze znacznymi kosztami.

Zatem sugerowanie „użyj klasy C ++ std :: queue” jako odpowiedzi na pytanie szukające biblioteki implementującej kolejkę w C jest czymś więcej niż sugerowaniem „użyj celu C” i „wywołaj klasę Java java.util.Queue używając JNI” lub „wywołaj bibliotekę CPython” - Cel C jest właściwie nadzbiorem języka C (w tym C99), a biblioteki Java i CPython można wywołać bezpośrednio z C bez konieczności przenoszenia niepowiązanego kodu do języka C ++.

Oczywiście możesz dostarczyć fasadę C do biblioteki C ++, ale kiedy już to zrobisz, C ++ nie różni się niczym od Javy czy Pythona.

Zdaję sobie sprawę, że nie jest to ani profesjonalna, ani szczególnie dobra odpowiedź, ale dla mnie to po prostu dlatego, że naprawdę lubię C. C jest małe i proste i mogę zmieścić cały język w moim mózgu, C ++ zawsze wydawał mi się ogromnym bałaganem przy wszelkiego rodzaju warstwach ciężko mi narzekać. W związku z tym stwierdzam, że za każdym razem, gdy piszę C ++, spędzam znacznie więcej czasu na debugowaniu i uderzaniu głową w twarde powierzchnie, niż kiedy koduję C.Znowu zdaję sobie sprawę, że wiele z tego jest w dużej mierze wynikiem mojej własnej „ignorancji”.

Jeśli wybiorę, napiszę wszystkie rzeczy wysokiego poziomu, takie jak interfejs i interakcja z bazą danych w Pythonie (lub prawdopodobnie C #) oraz wszystkie rzeczy, które muszą być szybkie w C. Dla mnie to daje mi to, co najlepsze ze wszystkich światów. Pisanie wszystkiego w C ++ wydaje się być najgorszym ze wszystkich światów.

Edycja: Chciałbym dodać, że myślę, że C z kilkoma funkcjami C ++ jest w dużej mierze złym pomysłem, jeśli masz zamiar pracować nad projektem przez kilka osób lub jeśli priorytetem jest łatwość utrzymania. Nie będzie zgody co do tego, co stanowi „kilka”, a które bity należy wykonać w C, a które w C ++, co ostatecznie prowadzi do bardzo schizofrenicznej bazy kodu.

C ++ po prostu nie jest obsługiwany w niektórych środowiskach rzeczywistych, takich jak systemy osadzone niskiego poziomu. I jest ku temu dobry powód: C z łatwością wystarcza do takich rzeczy, więc po co używać czegoś większego?

Nienawidzę programowania w C ++.

Może być kilka powodów:

• Brak wsparcia - nie każdy kompilator C jest także kompilatorem C ++. Nie wszystkie kompilatory są szczególnie zgodne ze standardem, nawet jeśli twierdzą, że obsługują C ++. Niektóre kompilatory C ++ generują beznadziejnie rozdęty i nieefektywny kod. Niektóre kompilatory mają straszne implementacje biblioteki standardowej. Programowanie w trybie jądra generalnie uniemożliwia korzystanie ze standardowej biblioteki C ++, a także niektórych funkcji językowych. Nadal możesz pisać kod w C ++, jeśli trzymasz się rdzenia języka, ale wtedy może być łatwiejsze przejście na C.
• Znajomość. C ++ to złożony język. Łatwiej jest nauczyć kogoś C niż C ++ i łatwiej jest znaleźć dobrego programistę C niż dobrego programistę C ++. (słowo kluczowe jest tutaj "dobre". Jest wielu programistów C ++, ale większość z nich nie nauczyła się poprawnie języka)
• Krzywa uczenia się - Jak wyżej, nauczenie kogoś C ++ to ogromne zadanie. Jeśli piszesz aplikację, która w przyszłości będzie musiała być utrzymywana przez innych, a ci inni mogą nie być programistami C ++, napisanie jej w C znacznie ułatwia opanowanie.

Nadal wolę pisać w C ++, kiedy mi się to udaje, i ogólnie myślę, że korzyści przeważają nad wadami. Ale widzę też argument przemawiający za używaniem C. w niektórych przypadkach.

Jest mnóstwo argumentów na temat programowania wbudowanego, wydajności i innych rzeczy, nie kupuję ich. C ++ łatwo porównuje się z C w tych obszarach. Jednak:

Niedawno po ponad 15 latach programowania w C ++ na nowo odkryłem swoje korzenie w C. Muszę powiedzieć, że chociaż w C ++ są dobre funkcje, które ułatwiają życie, jest też masa pułapek i coś w rodzaju „zawsze jest lepszy” sposób robienia rzeczy. Tak naprawdę nigdy nie jesteś zadowolony z rozwiązania, które zrobiłeś. (Nie zrozum mnie źle, to może być dobra rzecz, ale przeważnie nie).

C ++ daje nieskończone strzały. Co może być prawdopodobnie dobre, ale jakoś zawsze kończy się to za dużo. Oznacza to, że maskujesz swoje rozwiązania za pomocą „ładnych” i „ładnych” warstw abstrakcji, ogólności itp.

Wracając do C, odkryłem, że programowanie było naprawdę zabawne. Spędziwszy tyle czasu na modelowaniu i rozmyślaniu o tym, jak najlepiej wykorzystać dziedziczenie, stwierdzam, że programowanie w C w rzeczywistości sprawia, że ​​mój kod źródłowy jest mniejszy i bardziej czytelny. Zależy to oczywiście od poziomu samodyscypliny. Ale bardzo łatwo jest umieścić zbyt wiele abstrakcji w prostym kodzie, który nigdy nie jest potrzebny.

C ma tę główną zaletę, że możesz po prostu zobaczyć, co się naprawdę dzieje, kiedy spojrzysz na jakiś fragment kodu (tak, preprocesor: kompiluj z -E i wtedy to zobaczysz). Coś, co jest zbyt często nieprawdą, gdy spojrzysz na jakiś kod w C ++. Tam masz konstruktory i destruktory, które są wywoływane niejawnie na podstawie zakresu lub z powodu przypisań, masz przeciążenie operatorów, które może mieć zaskakujące zachowanie, nawet jeśli nie jest źle używane. Przyznaję, że jestem maniakiem kontroli, ale doszedłem do wniosku, że nie jest to taki zły nawyk dla programisty, który chce pisać niezawodne oprogramowanie. Chcę tylko mieć uczciwą szansę, aby powiedzieć, że moje oprogramowanie robi dokładnie to, co powinno, a jednocześnie nie ma złego samopoczucia w żołądku, ponieważ wiem, że wciąż może być w nim tyle błędów, że bym tego nie zrobił

C ++ ma również szablony. Nienawidzę ich i kocham, ale jeśli ktoś mówi, że w pełni ich rozumie, nazywam go kłamcą! Obejmuje to twórców kompilatorów, a także osoby zaangażowane w definiowanie standardu (co staje się oczywiste, gdy próbujesz go przeczytać). Jest tak wiele absurdalnie mylących przypadków narożnych, że po prostu nie jest możliwe rozważenie ich wszystkich podczas pisania rzeczywistego kodu. Uwielbiam szablony C ++ ze względu na ich moc. To naprawdę niesamowite, co można z nimi zrobić, ale mogą one również prowadzić do najdziwniejszych i najtrudniejszych do znalezienia błędów, jakie można (nie) sobie wyobrazić. I te błędy rzeczywiście się zdarzają, a nawet nie rzadko. Czytanie o zasadach rozwiązywania szablonów w C ++ ARM prawie przyprawia mnie o eksplozję. I daje mi to złe wrażenie, że tracę czas na czytanie komunikatów o błędach kompilatora, które mają kilka 1000 znaków, na które potrzebuję już 10 minut lub więcej, aby zrozumieć, czego kompilator faktycznie ode mnie chce. W typowym kodzie C ++ (biblioteki) często znajdujesz również dużo kodu w plikach nagłówkowych, aby umożliwić pewne szablony, co z kolei sprawia, że ​​cykle kompilacji / wykonywania są boleśnie powolne nawet na szybkich maszynach i wymagają rekompilacji dużych części kodu, gdy coś zmienisz tam.

C ++ ma również pułapkę na const. Albo unikasz const dla wszystkich z wyjątkiem najbardziej trywialnych przypadków użycia, albo prędzej czy później będziesz musiał go odrzucić lub refaktoryzować duże części bazy kodu, gdy ewoluuje, zwłaszcza gdy masz zamiar opracować ładny i elastyczny projekt obiektowy.

C ++ ma silniejsze pisanie niż C, co jest świetne, ale czasami mam wrażenie, że karmię Tamagotchi, kiedy próbuję skompilować kod C ++. Duża część ostrzeżeń i błędów, które zwykle z niego wynikają, nie dotyczy mnie, gdy robię coś, co nie zadziała, ale po prostu rzeczy, których kompilator nie lubi, gdy robię w ten sposób lub nie, bez przesyłania lub umieszczania tutaj dodatkowych słów kluczowych i tam.

To tylko niektóre z powodów, dla których nie lubię C ++ w przypadku oprogramowania, które piszę sam, używając tylko niektórych rzekomo solidnych bibliotek zewnętrznych. Prawdziwy horror zaczyna się, gdy piszesz kod w zespołach z innymi ludźmi. Prawie nie ma znaczenia, czy są bardzo sprytnymi hakerami C ++, czy naiwnymi początkującymi. Każdy popełnia błędy, ale C ++ celowo utrudnia ich znalezienie, a jeszcze trudniej jest je dostrzec, zanim się pojawią.

Z C ++ jesteś po prostu zagubiony bez ciągłego używania debuggera, ale lubię mieć możliwość zweryfikowania poprawności mojego kodu w mojej głowie i nie muszę polegać na debugerze, aby znaleźć mój kod działający na ścieżkach, których nigdy bym nie przewidział. Właściwie staram się uruchomić cały kod w mojej głowie i próbować wziąć wszystkie jego gałęzie, nawet w podprogramach itp. I używać debuggera tylko od czasu do czasu, aby zobaczyć, jak ładnie przebiega przez wszystkie przytulne miejsca, które dla niego przygotowałem. Pisanie i wykonywanie tak wielu przypadków testowych, że wszystkie ścieżki kodu zostały użyte we wszystkich kombinacjach z różnymi dziwnymi danymi wejściowymi, jest po prostu niemożliwe. Więc możesz nie wiedzieć o błędach w programach C ++, ale to nie znaczy, że ich nie ma. Im większy projekt C ++, tym mniejsza staje się moja pewność, że nie będzie zawierał wielu niewykrytych błędów, nawet jeśli będzie działał doskonale ze wszystkimi danymi testowymi, które mamy pod ręką. W końcu wyrzucam go na śmieci i zaczynam od nowa z jakimś innym językiem lub kombinacją innych języków.

Mógłbym kontynuować, ale wydaje mi się, że już jasno przedstawiłem swój punkt widzenia. Wszystko to sprawiło, że czułem się bezproduktywny, gdy programowałem w C ++ i straciłem pewność co do poprawności własnego kodu, co oznacza, że ​​nie będę go już więcej używać, podczas gdy nadal używam i polegam na kodzie C, który napisałem ponad 20 Lata temu. Może to po prostu dlatego, że nie jestem dobrym programistą C ++, a może bycie całkiem dobrym w C i innych językach pozwala mi rozpoznać, jakim jestem lamerem, jeśli chodzi o C ++, i że nigdy nie będę w stanie tego w pełni pojąć .

Życie jest krótkie...

W osadzonych środowiskach niskiego poziomu niektórzy „inżynierowie oprogramowania” będą mieli doświadczenie w zakresie EE i ledwo opanowali C. C ++ jest bardziej złożony i niektórzy z nich po prostu boją się uczyć nowego języka. Zatem C jest używany jako najniższy wspólny mianownik. (Zanim zasugerujesz pozbycie się tych gości, są co najmniej tak samo ważni, jak specjaliści od CS, którzy nie rozumieją hardkorowych analogów).

Mówiąc z doświadczenia w odziedziczeniu i utrzymaniu obu: straszny projekt w C jest trudny do zrozumienia, rozwinięcia i przekształcenia w coś użytecznego.

Okropny projekt w C ++ jest nieskończenie gorszy, ponieważ losowe warstwy abstrakcji powodują, że twój mózg wędruje po bazie kodu, próbując dowiedzieć się, który kod zostanie wykonany w jakich okolicznościach.

Jeśli mam pracować z inżynierami, o których wiem, że nie stworzą świetnych projektów, wolałbym mieć ten pierwszy niż drugi.

Nie widzę powodu innego niż osobista niechęć, nawet do programowania systemów wbudowanych i podobnych rzeczy. W C ++ płacisz narzut tylko za funkcje, których używasz. Możesz użyć podzbioru C C ++ w niektórych sytuacjach, w których narzut C ++ jest dla Ciebie zbyt wysoki. To powiedziawszy, myślę, że niektórzy programiści C przeceniają narzut niektórych konstrukcji C ++. Podam kilka przykładów:

• Klasy i funkcje składowe mają zerowy narzut w porównaniu do normalnych funkcji (chyba że używasz funkcji wirtualnych, w takim przypadku nie ma narzutu w porównaniu do używania wskaźników do funkcji)
• Szablony mają bardzo mały narzut (najczęściej nie ma go wcale)

Jednym z ważnych powodów może być sytuacja, gdy programujesz dla platformy, która nie ma porządnego kompilatora C ++ (w ogóle nie ma kompilatora C ++ lub kompilator istnieje, ale jest źle zaimplementowany i nakłada niepotrzebnie duże obciążenie na niektóre funkcje C ++).

Po co ograniczać mówienie po angielsku? Być może byłbyś bardziej kreatywnym autorem w języku serbskim.

To ten sam argument, z oczywistymi błędami. Jeśli masz zadanie, a Twoje wygodne narzędzia skutecznie je rozwiązują, prawdopodobnie nie bez powodu użyjesz wygodnych narzędzi.

C ++ ma znacznie dłuższą krzywą uczenia się. C ma tylko kilka konstrukcji, o których musisz wiedzieć, a następnie możesz zacząć kodować potężne oprogramowanie. W C ++ musisz nauczyć się podstawy C, potem OO i programowania ogólnego, wyjątków itp. Po pewnym czasie możesz znać większość funkcji i prawdopodobnie będziesz z nich korzystać, ale nadal nie wiesz, jak kompilator będzie przetłumacz je, jakie ukryte narzuty mają, czy nie. Zajmuje to dużo czasu i energii.

W przypadku profesjonalnego projektu argument ten może się nie liczyć, ponieważ można zatrudnić osoby, które już bardzo dobrze znają C ++. Ale w projektach Open Source, gdzie C jest nadal szeroko używany, ludzie wybierają język, który im się podoba i potrafią się nim posługiwać. Weź pod uwagę, że nie każdy programista OS jest zawodowym programistą.

Chciałbym sprawdzić odpowiedź Dana Olsona. Uważam, że ludzie boją się potencjalnie niebezpiecznych i przynoszących skutki odwrotne do zamierzonych właściwości C ++ i jest to uzasadnione. Ale w przeciwieństwie do tego, co mówi Dan, nie sądzę, aby zwykłe podjęcie decyzji o standardzie kodowania było skuteczne z dwóch powodów:

1. Ściśle egzekwowanie standardów kodowania może być trudne
2. Znalezienie dobrego może być bardzo trudne.

Myślę, że ten drugi powód jest tutaj znacznie ważniejszy niż pierwszy, ponieważ decyzja dotycząca standardu kodowania może łatwo stać się kwestią polityczną i podlegać późniejszej rewizji. Rozważ następujący uproszczony przypadek:

1. Możesz używać kontenerów STL, ale nie możesz używać szablonów we własnym kodzie.
2. Ludzie zaczynają narzekać, że byliby bardziej produktywni, gdyby pozwolono im tylko zakodować tę lub inną klasę szablonu.
3. Standard kodowania został zmieniony, aby to umożliwić.
4. Zsuń nachylenie do zbyt skomplikowanego standardu kodowania, którego nikt nie przestrzega, i używaj dokładnie tego rodzaju niebezpiecznego kodu, któremu norma miał zapobiec, w połączeniu z nadmierną biurokracją otaczającą standard.

(Alternatywa polegająca na tym, że standard nie jest korygowana w kroku 3, jest empirycznie zbyt nieprawdopodobna do rozważenia i i tak nie byłaby o wiele lepsza).

Chociaż kilka lat temu używałem C ++ do prawie wszystkiego, zaczynam mocno czuć, że C jest preferowany w zadaniach niskiego poziomu, które muszą być obsługiwane przez C lub C ++, a wszystko inne powinno być zrobione w innym język całkowicie. (Jedynymi możliwymi wyjątkami są niektóre specyficzne domeny z problemami o wysokiej wydajności, wrt. Blitz ++ )

Używam C lub przynajmniej eksportuję interfejs C, kiedy piszę kod biblioteki.

Nie chcę źle określonych kłopotów z ABI.

Nigdy nie widziałem żadnych argumentów przemawiających za używaniem C zamiast C ++, które uważam za przekonujące. Myślę, że większość ludzi boi się pewnych funkcji, które oferuje C ++, często jest to uzasadnione. Jednak to mnie nie przekonuje, ponieważ za pomocą standardów kodowania można wymusić, czy używać pewnych funkcji, czy nie. Nawet w C jest wiele rzeczy, których chciałbyś uniknąć. Całkowite odrzucenie C ++ oznacza w istocie stwierdzenie, że nie oferuje on żadnych namacalnych korzyści w porównaniu z C, które pomogłyby w napisaniu lepszego kodu, co jest poglądem, który uważam za całkowicie ignorancki.

Poza tym ludzie zawsze podnoszą sytuację platform, na których nie ma kompilatora C ++. Z pewnością C byłby tutaj odpowiedni, ale myślę, że obecnie trudno byłoby znaleźć taką platformę.

Jeden punkt, którego jeszcze nie widziałem, a który moim zdaniem jest najważniejszy:

Większość bibliotek, których używam na co dzień, to biblioteki C z powiązaniami dla Pythona, Ruby, Perla, Javy itp. Z tego co widziałem, dużo łatwiej jest opakować biblioteki C 19 różnymi powiązaniami językowymi niż jest zawijanie bibliotek C ++.

Na przykład nauczyłem się Kairu i od tego czasu go w 3 lub 4 różnych językach. Wielka wygrana! Wolałbym napisać program, który będzie można ponownie wykorzystać w przyszłości, a napisanie takiego, który można łatwo zaadaptować do innych języków programowania, jest tego skrajnym przypadkiem.

Wiem, że można powiązać biblioteki C ++, ale AFAICT to nie to samo. Używałem Qt (v3 i v4) w innych językach i nie jest tak przyjemny w użyciu: mają ochotę pisać C ++ w jakimś innym języku, a nie jak natywne biblioteki. (Musisz przekazać znaki metody w C ++ jako łańcuchy!)

C ++ jest prawdopodobnie lepszym językiem, jeśli piszesz funkcję, która ma być używana raz, lub jeśli myślisz, że cały świat jest C ++. C wydaje się łatwiejszym językiem, jeśli od początku projektujesz pod kątem przenoszenia języka.

Rozwój jądra systemu Windows nie obsługuje języka C ++ (niestety).

Można przeczytać o tym, dlaczego zabawny rant Linus Torvalds sprzyja C tutaj

Natywny kod na komputerze Mac to obiektyw-c. Natywny kod na komputerze to c (window.h) lub c ++ (mfc). Oba te środowiska pozwolą ci używać c z niewielkimi lub żadnymi zmianami. Kiedy chcę, aby biblioteka kodu była wieloplatformowa, ansi c wydaje się dobrym wyborem.

Przychodzi mi do głowy kilka powodów.

Może nie istnieć zadowalający kompilator C ++. C ++ jest znacznie większym językiem, a kompilatory C uruchamiałem na systemach, które nie byłyby w stanie obsłużyć współczesnego C ++.

Osoba pytająca lub osoby, z którymi pracuje, mogą znać C, ale nie C ++.

Projekt może być w C. Chociaż możliwe jest dodanie niektórych funkcji C ++ do C, może to łatwo doprowadzić do nie do utrzymania bałaganu. Sugerowałbym wybranie jednego lub drugiego języka (zwykle C ++, jeśli jest to praktyczne).

Pytający może mieć przestarzały widok krzywej uczenia się C ++. (Przy prawidłowym podejściu jest to łatwiejsze niż w C. Większość książek wprowadzających, które widziałem, nie podchodzi do tego poprawnie.)

Pamiętaj, że C i C ++ to dwa różne języki iz czasem coraz bardziej się od siebie różnią. Kodowanie w obu naraz jest złym pomysłem, a używanie podobnego do C podzbioru C ++ pomija większość zalet C ++.

Jeśli pracujesz w środowisku z dwoma językami, możesz użyć C dla niektórych funkcji niskiego poziomu krytycznych dla wydajności i bardziej funkcjonalnego / języka wysokiego poziomu, takiego jak C # / Java dla logiki biznesowej. Jeśli kod C ++ jest używany do tych funkcji, C-Wrappery są wymagane dla JNI / niezarządzanego kodu, co sprawia, że ​​rzeczy są bardziej złożone niż używanie samego C.

Używam C ++ z programowaniem w C z dwóch powodów:

• vector i string odciągnąć ode mnie zarządzanie pamięcią macierzy
• ścisłe sprawdzanie typu i rzutów, aby ostrzec i / lub wyłapać wszystkie niedogodności, których inaczej bym przegapił.

Więc to C naprawdę pożycza kilka C ++, ale używa kompilatora c ++ tak często, jak tylko mogę. Jak ktoś inny mówi w odpowiedziach, stwierdzam, że teraz w ten sposób zbieram więcej C ++ i tam, gdzie C byłoby zbyt wciągające, używam C ++. Monitor / Lock przy użyciu RAII jest jednym z tych, z których ostatnio korzystałem podczas pracy z programami wielowątkowymi i inną podobną konstrukcją do otwierania / zamykania plików.

Myślę, że C jest bardziej przenośny. Pracowałem około 5 lat temu, przenosząc kod na wiele odmian unixa (AIX, Irix, HPUX, Linux). Kod w C był łatwy do przeniesienia, ale mieliśmy różne problemy z przenoszeniem części kodu C ++. Może to były niedojrzałe środowiska programistyczne, ale z tego powodu wolałbym używać C zamiast C ++ ...

1. C jest prostym językiem, C ++ nie. Dla wielu ludzi C ++ jest po prostu zbyt skomplikowany, aby go w pełni opanować, zobacz http://en.wikipedia.org/wiki/C%2B%2B#Criticism .

2. Ze względu na złożoność różni programiści zwykle opanowują tylko różne podzbiory języka. To sprawia, że ​​czytanie kodu innych ludzi jest bolesne.

3. Złożoność, pułapki języka zbytnio rozpraszają, a czasami szkodzą produktywności. Zamiast skupiać się na samej pracy, często walczyłem z samym językiem. Java / python są bardziej produktywnymi alternatywami.

4. Debugowanie uszkodzonego kodu C jest zwykle znacznie prostsze niż debugowanie uszkodzonego kodu C ++.

5. W przeciwieństwie do Java / C #, standardowa biblioteka C ++ osiąga niewiele poza zakresem standardowej biblioteki C.

6. Niektórzy znani programiści, tacy jak Linus Torvalds (Linux) i Richard Stallman (Emacs) nie lubią C ++.

Większość programistów przyjmuje za pewnik, że każdy uważa jakość za wysoki priorytet. Nie zawsze tak jest. Jeśli jesteś przyzwyczajony do C, C ++ może wydawać się, że robi za dużo dla ciebie za kulisami. Ścisłość sprawdzania typów w C ++ może również wydawać się ograniczająca. Wiele osób jest skłonnych zaryzykować wprowadzenie tego rodzaju błędów, którym C ++ może pomóc, aby uniknąć tych „niedogodności”.

Przychodzą mi do głowy trzy powody. Jednym z nich jest to, że C jest bardziej odpowiedni dla systemów wbudowanych, ze względu na mały rozmiar jego plików binarnych i szerszą dostępność kompilatorów C w dowolnym systemie. Drugi to przenośność: C to mniejszy język, a kod ANSI C można skompilować wszędzie. Łatwiej jest przełamać przenośność w C ++. Ostatni to sam język. C ++ jest trudniejszy i zdecydowanie jest to bardzo słabo zaprojektowany język. Zastrzeżenia Torvaldsa zostały zgłoszone powyżej. Możesz również zapoznać się z często zadawanymi pytaniami w języku C ++ ( http://yosefk.com/c++fqa/ ).

Możliwość przenoszenia może stanowić problem. W przeciwieństwie do odpowiedzi Gordona Carpentera-Thompa, sugerowałbym, że jest to raczej wsparcie dla różnych wersji libstdc ++ w czasie wykonywania na różnych wersjach linux / unix. Zobacz ten link, aby uzyskać dobrą dyskusję na ten temat. Mały fragment:

Kod obsługi środowiska wykonawczego używany przez różne części aplikacji C ++ musi być zgodny. Jeśli jedna część programu wymaga dynamicznego przesyłania lub przechwytywania obiektów dostarczonych przez inną, obie części muszą uzgodnić pewne szczegóły implementacji: jak znaleźć vtables, jak rozwinąć stos i tak dalej.

Dla C ++ i kilku innych języków obsługiwanych przez GCC z podobnymi funkcjami, takie szczegóły są określone przez ABI C ++. Za każdym razem, gdy zmieni się ABI używany przez GCC, otrzymasz niezgodne biblioteki utworzone przez różne wersje GCC. To samo dotyczy zwykłego C, ale C ABI jest znacznie prostszy i istnieje znacznie dłużej, więc jest dość stabilny.

Mogę podążać za wieloma sugestiami w obu kierunkach. Ale ostatecznie sprowadza się to do a) porównywalnego prostego b) porównywalnego kompleksu.

Nie mam pojęcia, czy ktoś „wymyślił” rodzaj pomiaru złożoności języka.

W skali od 0 do 10 prawdopodobnie oceniłbym C na 2 lub 3, podczas gdy C ++ na 8-10. Twierdziłbym, że C ++ jest jednym z najbardziej złożonych języków, ale nie znam np. Ady, PL1 i tym podobnych, więc może nie jest tak skomplikowany w porównaniu z jakimś innym językiem.

C ++ dziedziczy całą złożoność języka C, więc nie może znajdować się poniżej poziomu złożoności C.

Ja ze swojej strony czułbym się znacznie bardziej komfortowo używając jakiegoś języka skryptowego i C. Na koniec należy odpowiedzieć na następujące pytanie. "Czy więcej zawsze jest lepsze?"

Najbardziej użyteczną rzeczą, jaką znalazłem w C, jest brak przestrzeni nazw i przeciążeń: nazwy funkcji i symboli są unikalnymi identyfikatorami. Aby znaleźć miejsca, w których te symbole są używane, możesz po prostugrep przejrzeć pliki z kodem źródłowym, a wyniki wyszukiwania pokażą lokalizacje.

Jest to niezbędne przy podłączaniu nowej funkcji lub komponentu do starego i splątanego systemu.

Nie można tego łatwo zrobić w C ++ bez wyrafinowanego narzędzia do tworzenia wykresów wywołań.

Większość ludzi wydaje się myśleć, że C i C ++ są w jakiś sposób powiązane, ale niestety się mylą. C ++ to zupełnie inny język niż C.

W C ++ myślisz o obiektach i jak są one ze sobą powiązane. W C myślisz w kategoriach API. To jak różnica między dniem a 17.

Słaba analogia: jeśli ktoś doda chiński do angielskiego i nazywa go angielskim ++, prawdopodobnie nie czułbyś się komfortowo dodając chińską linię do swojego ostatniego listu miłosnego, ponieważ o wiele łatwiej jest wyrazić miłość w tej części angielskiego ++.

Oto wszystkie powody, dla których warto ograniczyć projekt do języka C:

• szybsza kompilacja, ponieważ język jest znacznie prostszy
• wymaga mniejszej obsługi w czasie wykonywania, co czyni go bardziej odpowiednim dla środowisk niskopoziomowych
• znacznie łatwiejsze w obsłudze z innymi językami
• obsługuje tablice o zmiennej wielkości na stosie
• łatwiejszy do odczytania kod asemblera, ponieważ nie ma zniekształcenia nazwy
• umożliwia łatwe łączenie kodu produkowanego przez różne kompilatory, ponieważ jest to de facto standardowy binarny interfejs aplikacji