🚀 go-pugleaf

> > A co jest złego w MISRA-C++?
> 
> Nikt go nie używa.

Właśnie pytam, dlaczego.

> Po prostu jest niekoszerny.

Ciekawa obserwacja. Ale w takim razie ogólnie jesteśmy w lesie, bo to nie powinno być kryterium wyboru metod albo technologii.
Niemniej, jeśli nikt nie używa C++, to po co dyskutujemy o wyjątkach w C++?

> Ktoś napisał w języku z 
> silnym typowaniem i fikuśnymi wyjątkami kod w asemblerze który przedarł 
> się przez code review, weryfikację i był sterowany przez księgowych.

Co trzeba poprawić?

> Zaznaczam że gdyby ktokolwiek obecnie zapytał mnie jak to zrobic to w 
> przypływie mojej ignorancji napisałbym klasę do obsługi arytmetyki z 
> saturacją, być może z możliwością wymiany jej na bezpośrednie wsparcie 
> hardware co przecież dziwne nie jest.

I w jaki sposób by to pomogło rakiecie Ariane?
Ona rozwaliła się nie przez to, że ktoś napisał brzydki kod, tylko przez to, że bezrefleksyjnie złożono do kupy moduły z nowej i starej rakiety.
Twoja klasa nie pomogłaby dokładnie tak samo, jak Ada nie pomogła. Przez tych samych księgowych.
Tu widać, że programiści, nawet jeśli czasem są problemem, to zwykle nie są rozwiazaniem. Sorry.

> > Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.
> 
> Tak. Na przykład Verilog.

No właśnie. Czemu nie VHDL?

> Na codzień mam do czynienia z VHDL. To taka ada + troche ekstra składni. 
> Pisanie bezpieczne w tym języku polega głównie na obchodzeniu przez 
> programistów silnego typowania chałupniczymi workaroundami. Stąd 
> popularnośc Veriloga, można tam pisać co się chce a i tak sie jakoś 
> skompiluje. Ludzie nie potrzebują bezpicznych jezyków i ograniczeń. 
> Ludzie są leniwi i potrzebują dodawać inta do stringa a wynik ma być 
> taki jak ma być i już.

Bardzo ciekawa obserwacja.
I jak to można naprawić?

Tylko nie pisz, że "gdyby zatrudnili porządnych programistów...", bo to jest argument od czapy.

> >>> Unit testy nie wykrywają wyjątków. Chyba że mamy inne rozumienie tego terminu.
> >> ASSERT_THROW. ASSERT_NO_THROW. Całkiem fajnie wykrywają.
> > Ale to nie są unit testy.
> 
> To są narzędzia do wykrywania wyjątków w unit testach co oznacza że za 
> ich pomocą można pisać unit testy testujące wyjątki.

Nie, bo unit testy nie testują wyjątków. Chyba że mamy inne rozumienie tego terminu.

> Powtarzam, wyjątek czy nie, nie jest kwestią funkcji generycznych jego 
> obsługa.

Ale one nie muszą go obsługiwać (pojęcie "obsługi wyjątków" jest w ogóle słabe, bo nie wskazuje, co się do tej obsługi zalicza; zwijanie stosu i omijanie istniejącego kodu to obsługa czy nie?). Ważne, żeby te wszystkie rozgałęzienia były pokryte testami. A nie są. Więc jest źle.

-- 
Maciej Sobczak * http://www.inspirel.com