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...