Czy istnieją jakieś rzeczywiste przypadki dla C ++ bez wyjątków? [Zamknięte]

W Kiedy używać C zamiast C ++, a C ++ ponad C? istnieje oświadczenie wrt. do rozmiaru kodu / wyjątków C ++:

Odpowiedzi Jerry (między innymi):

(...) trudniej jest tworzyć naprawdę małe pliki wykonywalne w C ++. W naprawdę małych systemach i tak rzadko piszesz dużo kodu, a dodatkowe (...)

na co zapytałem, dlaczego tak jest, na co Jerry odpowiedział:

najważniejsze jest to, że C ++ obejmuje obsługę wyjątków, co (przynajmniej zwykle) dodaje pewne minimum do rozmiaru pliku wykonywalnego. Większość kompilatorów pozwoli ci wyłączyć obsługę wyjątków, ale kiedy to zrobisz, wynik nie jest już całkiem C ++. (...)

czego tak naprawdę nie wątpię w technicznym świecie rzeczywistym.

Dlatego jestem zainteresowany (wyłącznie z ciekawości), aby usłyszeć z przykładów ze świata rzeczywistego, w których projekt wybrał C ++ jako język, a następnie postanowił wyłączyć wyjątki. (Nie tylko „nie używaj” wyjątków w kodzie użytkownika, ale wyłącz je w kompilatorze, abyś nie mógł rzucać ani wychwytywać wyjątków.) Dlaczego projekt zdecydował się to zrobić (nadal używa C ++, a nie C, ale nie wyjątki) - jakie są / były (techniczne) przyczyny?

Dodatek: Dla tych, którzy chcą rozwinąć swoje odpowiedzi, byłoby miło opisać, w jaki sposób obsługiwane są implikacje braku wyjątków:

• Kolekcje STL ( vector, ...) nie działają poprawnie (nie można zgłosić niepowodzenia alokacji)
• new nie można rzucać
• Konstruktory nie mogą zawieść

Prawie każda gra konsolowa dostępna w C ++ z wyjątkiem wyłączonym, nawet dzisiaj. W obliczu jest to domyślna konfiguracja kompilatorów C ++ ukierunkowanych na te konsole. Czasami nie można zagwarantować, że niektóre funkcje C ++ działają poprawnie na tych kompilatorach, np. Wielokrotne dziedziczenie (mam na myśli bardzo dobrze znany domyślny kompilator konsoli).

Kolejnym przykładem jest sprzętowy zestaw SDK Arduino usnig gcc bez wyjątku aktywowany w C ++ i inne rzeczy, takie jak brak STL .

Istnieje kilka technicznych powodów, dobrych lub złych, cokolwiek, to nie moja rada, ale powody, które słyszałem:

1. Większość konsol to naprawdę systemy osadzone z ograniczoną pamięcią i czasem przetwarzania. Być może nie będzie tak w przyszłych konsolach, ale obecne są nadal bardzo restrykcyjne w porównaniu do komputerów PC. Niektóre konsole przenośne są trudniejsze do zaprogramowania niż jakikolwiek smartfon, na przykład NDS. Funkcja wyjątku dodaje pamięć i trochę kosztuje prędkość, nawet jeśli jej nie używasz. Możesz to sprawdzić, nawet na PC.
2. Gry wideo na konsoli nie mogą ulec awarii. Muszą być przetestowane w taki sposób, aby uniknąć awarii lub ślepej uliczki, jakiegokolwiek showstopera. Dlatego producenci konsol proszą o dokładne sprawdzenie gier przed publikacją. Oznacza to również, że zarządzanie wyjątkami zwiększa koszty, które nie są tak naprawdę przydatne w przypadku gier konsolowych. Jest to na przykład lepsze w smartfonie, ponieważ mogą istnieć pewne sposoby odzyskania lub dodanie kodu, aby wysłać Ci problem. Zamknięte platformy, takie jak większość konsol, nie pozwalają na to. Tak więc system wyjątków nie jest tak naprawdę konieczny. „Musisz tylko sprawić, by działał poprawnie”. ;)
3. Zarządzanie wyjątkami, gdy nie zezwalasz na błędy i awarie, oznacza, że ​​musisz wdrożyć strategię zarządzania błędami. Taki system może być na tyle skomplikowany, że sprawi, że ktoś będzie pracował dużo czasu, aby był użyteczny. Twórcy gier nie mają luksusu pracować nad funkcjami, które uważa się za przydatne w przypadku awarii ...
4. Kompilator na to nie pozwala (jeszcze). Tak się stało.

Myślę, że wyjątki mogą być przydatne nawet w grach, ale to prawda, że ​​w grach konsolowych nie jest to tak naprawdę przydatne.

Aktualizacja:

Dodaję kolejny zaskakujący przykład: LLVM / CLang nie używa wyjątku ani RTTI z następujących powodów :

W celu zmniejszenia kodu i rozmiaru pliku wykonywalnego LLVM nie używa RTTI (np. Dynamiczny_cast <>) ani wyjątków. Te dwie funkcje językowe naruszają ogólną zasadę C ++: „płacisz tylko za to, czego używasz”, powodując wzdęcia, nawet jeśli wyjątki nigdy nie są używane w bazie kodu lub jeśli RTTI nigdy nie jest używane dla klasy. Z tego powodu wyłączamy je globalnie w kodzie.

To powiedziawszy, LLVM w szerokim zakresie wykorzystuje ręcznie walcowaną formę RTTI, która wykorzystuje szablony takie jak isa <>, cast <> i dyn_cast <>. Ta forma RTTI jest opcjonalna i można ją dodać do dowolnej klasy. Jest także znacznie bardziej wydajny niż dynamic_cast <>.

CLang jest dobrze znany ze swojej szybkości kompilacji i wyraźnych błędów, ale także z jednego rzadkiego kompilatora, który ma naprawdę łatwy do śledzenia kod.

Jerry powiedział: ... wynik nie jest już całkowicie C ++ , podczas gdy moja metafora jest taka, że jest to oczywiście C ++, tylko nieco inny dialekt, ponieważ programy wykorzystują inne formy, konwencje i style pisane.

Oto moje główne powody wyłączenia:

Kompatybilność binarna

Przekraczanie granic języka i tłumaczeń nie jest powszechnie dobrze zdefiniowane ani niezdefiniowane. Jeśli chcesz zagwarantować, że Twój program działa w domenie określonego zachowania, musisz poddać kwarantannie wyjątki w punktach wyjścia modułu.

Rozmiar pliku wykonywalnego

Oto binarne rozmiary programu bez wyjątków, który napisałem, zbudowałem bez włączonych wyjątków:

Bez wyjątków:

• pliki wykonywalne + zależności: 330
• końcowy plik wykonywalny pozbawiony (kompilacja wydania): 37

Z wyjątkami:

• pliki wykonywalne + zależności: 380
• końcowy plik wykonywalny pozbawiony (kompilacja wydania): 44

Przypomnienie: jest to zbiór bibliotek i programów, które zawierają zerowe rzuty / połowy. Flaga kompilator robi umożliwić wyjątków w C ++ biblioteki standardowej. Dlatego koszt w prawdziwym świecie jest większy niż 19% w tym przykładzie.

Kompilator: apple gcc4.2 + llvm. Rozmiary w MB.

Prędkość

Pomimo terminu „wyjątki zerowego kosztu” wciąż dodają pewne koszty ogólne, nawet jeśli nic się nie rzuca. W powyższym przypadku jest to program krytyczny pod względem wydajności (przetwarzanie sygnałów, generowanie, prezentacja, konwersje, z dużymi zestawami danych / sygnałami itp.). Wyjątki nie są konieczną funkcją w tym projekcie, a wydajność jest bardzo ważna.

Poprawność programu

Wydaje się to dziwnym powodem ... Jeśli rzucanie nie jest opcją, musisz napisać stosunkowo surowe, poprawne, dobrze przetestowane programy, aby zagwarantować, że Twój program działa poprawnie, a klienci poprawnie używają interfejsów (jeśli podasz mi zły argument lub zrobisz to nie sprawdzaj kodu błędu, to zasługujesz na UB). Wynik? Jakość wdrożenia znacznie się poprawia, a problemy szybko się naprawiają.

Prostota

Implementacje obsługi wyjątków nie są często aktualizowane. Dodają również dużo złożoności, ponieważ implementacja może mieć wiele wiele sekwencji wyjścia. Łatwiej jest czytać i obsługiwać bardzo złożone programy, gdy używają niewielkiego zestawu dobrze zdefiniowanych, wpisywanych strategii wyjścia, które pojawiają się i są obsługiwane przez klienta. W innych przypadkach implementacje mogą z czasem wprowadzić więcej rzutów lub ich zależności mogą je wprowadzić. Klienci nie mogą łatwo ani odpowiednio bronić się przed wszystkimi tymi wyjściami. Piszę i aktualizuję wiele bibliotek, często ewoluuję i ulepszamy. Próba utrzymywania tego w synchronizacji z wyjątkowymi sekwencjami wyjściowymi (w dużej bazie kodu) nie byłaby dobrym wykorzystaniem czasu i prawdopodobnie spowodowałaby dużo hałasu i kłopotów. Ze względu na zwiększoną poprawność programu i więcej testów,

Historia / istniejący kod

W niektórych przypadkach nigdy nie zostały wprowadzone z powodów historycznych. Istniejąca baza kodów nie korzystała z nich, zmiana programów mogła zająć wiele lat i uczynić je naprawdę brzydkimi z powodu nakładania się konwencji i implementacji.

Wady

Oczywiście są wady, największe to: Niezgodność (w tym binarna) z innymi bibliotekami oraz fakt, że będziesz musiał zaimplementować dużą liczbę programów, aby pasowały do ​​tego modelu.

Google nie akceptuje wyjątków w Przewodniku po stylach C ++ , głównie z powodów historycznych:

Na pierwszy rzut oka korzyści wynikające z zastosowania wyjątków przewyższają koszty, zwłaszcza w przypadku nowych projektów. Jednak w przypadku istniejącego kodu wprowadzenie wyjątków ma wpływ na cały kod zależny. Jeśli wyjątki można propagować poza nowym projektem, problematyczne staje się także zintegrowanie nowego projektu z istniejącym kodem bez wyjątków. Ponieważ większość istniejącego kodu C ++ w Google nie jest przygotowana na wyjątki, stosunkowo trudno jest przyjąć nowy kod, który generuje wyjątki.

Biorąc pod uwagę, że istniejący kod Google nie toleruje wyjątków, koszty korzystania z wyjątków są nieco wyższe niż koszty w nowym projekcie. Proces konwersji byłby powolny i podatny na błędy. Nie uważamy, aby dostępne alternatywy dla wyjątków, takie jak kody błędów i stwierdzenia, stanowiły znaczne obciążenie.

Odradzamy stosowanie wyjątków nie z powodów filozoficznych lub moralnych, ale z praktycznych. Ponieważ chcielibyśmy korzystać z naszych projektów open source w Google i jest to trudne, jeśli projekty te korzystają z wyjątków, musimy odradzać wyjątki również w projektach Google open source. Prawdopodobnie sytuacja wyglądałaby inaczej, gdybyśmy musieli to zrobić od nowa.

Istnieje wyjątek od tej reguły (bez słów) dla kodu Windows.

(Nacisk redakcji)

Qt prawie nigdy nie używa wyjątków. Błędy w Qt są oznaczone kodami błędów i sygnałami. Oficjalnie podanym powodem jest:

Po uruchomieniu Qt wyjątki nie były dostępne dla wszystkich kompilatorów, które musiały być obsługiwane przez Qt. Dzisiaj staramy się zachować spójność interfejsów API, aby moduły, które w przeszłości nie używały wyjątków, na ogół nie otrzymały nowego kodu z dodanymi wyjątkami.

Dlaczego QT korzysta z tak niewielu wyjątków?

Dzisiaj powszechną krytyką Qt jest to, że bezpieczeństwo wyjątków nie jest pełne.

Symbian C ++ (używany w niektórych telefonach Nokia) nie korzysta z wyjątków, przynajmniej nie bezpośrednio, ponieważ kompilatory C ++ nie wdrożyły ich niezawodnie, gdy Symbian został opracowany po raz pierwszy.

Ja / nigdy / używam wyjątków. Istnieje wiele powodów, ale dwa główne powody to to, że nigdy nie potrzebowałem ich do stworzenia solidnego kodu i że zmniejszają one wydajność w czasie wykonywania.

Pracowałem nad kodem produkcyjnym, który zarówno używa, jak i wyłącza wyjątki - kod, który dopuszczał wyjątki, był jednakowo gorszy. W niektórych miejscach zastosowano wyjątki do prawdziwej kontroli przepływu, a nie do obsługi błędów, co jest bardzo ciężkie, antykonkurencyjne i trudne do debugowania. Ogólnie problemy z debugowaniem w kodzie wypełnionym wyjątkiem były trudniejsze niż w kodzie bez wyjątku - częściowo ze względu na stos i wewnętrzne trudności mechanizmu wyjątku, ale znacznie więcej niż to z powodu leniwego kodu, który był zachęcany jako wynik dostępności obsługi wyjątków.

W samych wyjątkach nie ma nic poważnego źle / jeśli nie zależy ci na wydajności / i nie masz czasu, aby zrobić coś właściwie - są one językową funkcją obsługi błędów i dobrym zamiennikiem właściwego mechanizmu obsługi błędów. Są jednak prawie zawsze / lepsze / sposoby radzenia sobie z błędami - tak jak w przypadku własnej logiki (trudno to rozwinąć - jest to prawie zdrowy rozsądek). Jeśli to nie twój błąd, ale pochodzi z biblioteki (np. Biblioteki standardowej), musisz uszanować wybór wyjątków lub mieć awarię, ale zawsze kwestionowałbym ten wybór. Nigdy nie widziałem sytuacji, w której wyjątki byłyby rzeczywiście najlepszym rozwiązaniem.

Asercje są bardziej debugowalne, kody błędów mają mniejszą wagę ... między nimi, jeśli są właściwie używane, łatwiej jest czytać, debugować i utrzymywać kod, który jest szybszy. Wygrywa cały ...

W standardzie kodowania Joint Strike Fighter C ++ autorstwa Bjarne i in. al. wyjątki są zakazane ze względu na trudne wymagania myśliwców w czasie rzeczywistym.

JSF ++ jest przeznaczony do aplikacji w czasie rzeczywistym i krytycznych dla bezpieczeństwa (oprogramowanie do sterowania lotem). Jeśli obliczenia trwają zbyt długo, ktoś może umrzeć. Z tego powodu musimy zagwarantować czasy reakcji i nie możemy - przy obecnym poziomie wsparcia narzędzi - robić tego w wyjątkach. W tym kontekście nawet bezpłatna alokacja sklepu jest zabroniona! W rzeczywistości zalecenia JSF ++ dotyczące obsługi błędów symulują użycie wyjątków w oczekiwaniu na dzień, w którym będziemy dysponować narzędziami umożliwiającymi prawidłowe działanie, tj. Używanie wyjątków.

Cytat z Bjarne C ++ FAQ .

Pamiętaj, że C ++ prawdopodobnie obsługuje najszerszą gamę oprogramowania ze wszystkich języków ...

Jest to dość ważne w projektowaniu bibliotek C ++. Często z interfejsem C trochę nieprzyjemnie jest wyrzucać klientowi wyjątek z biblioteki innej firmy. Chodzi o to, że jeśli twoja biblioteka rzuca się, odcinasz grupę klientów, którzy z niej skorzystaliby, biorąc pod uwagę, że miała ona gwarancję braku rzucania (z dowolnego powodu, dla którego klient ma ograniczenie wyjątków).

Osobiście widziałem przypadki nadużywania wyjątków, gdy zespołowi polecono „wrzucić wyjątek”, ilekroć dzieje się coś nie tak strasznego. Oczywiście widzisz tutaj błąd - wyjątek został zgłoszony w kodzie, zanim ktokolwiek wymyślił, co z tym zrobić. Ten projekt miał kilka awarii, ponieważ te głębokie rzuty czasami się wycofywały.

Być może pod tym względem warto wspomnieć o Embedded C ++ . Embedded C ++ to odmiana C ++ zaprojektowana (oczywiście wystarczająco) dla systemów osadzonych. Jest to w zasadzie właściwy podzbiór C ++, z usuniętymi (między innymi) szablonami, przestrzeniami nazw i obsługą wyjątków.

Powinienem dodać, że chociaż EC ++ zachwiał się odrobinę, gdy był nowy, wydaje się, że w większości ucichły. Nie jestem pewien, czy ludzie stracili zainteresowanie, czy też ich pierwsza próba była po prostu tak doskonała, że ​​nikt nie widział powodu, by się tym zajmować przez dekadę.<closed captioning for the humor impaired>Yeah, right!</closed captioning>

Dobrym przykładem jest programowanie w trybie jądra.

Możesz użyć C ++ tam dla czystszego kodu, ale bez wyjątków. Nie ma dla nich biblioteki wykonawczej, a obsługa wyjątków używa zbyt dużej pamięci stosu, która jest bardzo ograniczona w jądrze (eksperymentowałem z wyjątkami C ++ w jądrze systemu Windows NT, a rzucanie i odwijanie wyjątków zjada połowę dostępnego stosu - bardzo łatwo uzyskać przepełnienie stosu i zawiesić cały system).

Zazwyczaj definiujesz własne newi deleteoperatorów. Znalazłem też całkiem przydatne placement newodniesienia do wartości rc i a +++. Nie można używać STL ani innych bibliotek trybu użytkownika C ++, które opierają się na wyjątkach.

Gdy próbujesz utrzymać pamięć wykonywalną w dół. Zwykle wykonywane w systemach wbudowanych (lub mobilnych). W przypadku aplikacji komputerowych nie jest to nigdy potrzebne, jednak na serwerach można rozważyć, czy chcesz jak najwięcej pamięci RAM dla serwera WWW lub SQL.