> Nie, tu padło jakieś hasło "C++ zachęca do pisania w stylu "write
> once, debug endlessly"". Problem w tym że to jest walidne w każdym
> języku a w c++ z roku na rok o dziwo coraz mniej.

Tak. Oczywiście potrzeba, żeby programiści z roku na rok też robili postępy w tym,
jak korzystają z tego języka.

> > Niezupełnie. W takich systemach może być wymaganie na pokrycie testami każdej
ścieżki.
>
> Nie. W typowym systemie nie wymaga się pokrycia *każdej* ścieżki, wymaga
> się pokrycia określonego procentu.

Co to jest "typowy system"? Bo w konteście całej ludzkiej aktywności
programistycznej, w ogóle wymaganie weryfikacji czegokolwiek jest niszowe. A jak
jesteśmy w niszach, to trudno mówić o "typowym systemie".
W niszach są standardy i procesy. Nie spotkałem wymagań w procentach pokrycia.

> Ba, wymaga się pokrycia nie tylko
> ściezki wykonywania kodu, ale np. zbioru wartości danych zmiennych.

Też w procentach?

> Jeśli masz kilkaset tyś lini kodu to nie jest mozliwe pokrycie go w 100%

No to może za dużo jest tych linii? Albo ktoś je napisał a dopiero potem zorientował
się, że warto by zrobić jakąś weryfikację. To niedobrze.

> Ludzie robiący systemy krytyczne używają specjalistycznych
> narzędzie do oceny czy dany kod spełnia warunki czy nie, często są to
> zabawki oparte o randomizacje. I prawie nigdy to nie jest 100%. 100% to
> można sobie osiągnąć w kodzie do migania diodą czy przedsionkiem serca.

Trochę się motasz. Przedsionek serca to system krytyczny. Miganie diodą też nim może
być, zależy co to za dioda. A jeśli masz system, w którym ktoś napisał kilkaset tyś.
linii a potem się zorientował, że nie może ich pokryć, to może jednak ten system od
samego początku nie był tak bardzo krytyczny i tylko ludzie sobie dodają fasonu
twierdząc, że jest.

> > Jeżeli są wyjątki, to tych ścieżek nawet nie widać
>
> Mało kto patzy na kod.

:-D

W takim razie faktycznie mówimy o różnych niszach.

> Do testowania pokrycia stosuje się automatykę.
> Ona widzi wyjątki tak samo jak logjmp.

Nie. Nie widzi.
Cytat ze standardu do F-35 (bo tam zaczęliśmy):

"
AV Rule 208:
C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
Rationale: Tool support is not adequate at this time.
"

Problem w tym, że nadal jest "not adequate". I bardzo możliwe, że zawsze tak będzie.

> Zmartwie Cie. Zazwyczaj dostep do całego kodu nie jest potrzebny jeśli
> *formalnie* coś udowodnisz w module w środku. To że przez funkcję
> generyczną przelatują wyjąki i robią bałagan ze stanem czegośtam nie
> jest absolutnie problemem funkcji generycznej tylko kodu na zewnątrz.

Zmartwię Cię. Wymaganie pokrycia dotyczy kodu obiektowego a nie źródłowego. Na tym
poziome nie ma już wiedzy o tym, który kawałek kodu był generyczny a który nie.

> Znowu Cie zmartwie: możesz pokryć tą generyczną funkcję testami w 100% a
> i tak ktoś rzuci wyjątkiem

Nie rzuci, bo jest zakaz. Właśnie po to.

> w przemyśle
> nawet w aplikacjach do latania stosuje się śmiesze liczby w rodzaju 99%

A dlaczego nie dało się pokryć tego brakującego 1%?

> Zleceniodwaca może oczywiście chcieć 100% ale wtedy będzie czekał na
> software przez 10 lat.

F-35 próbują zrobić od 1992. 10 lat to by był megasukces. :-)

> System w którym lata milion wyjątków jest do dupy. Ale narzekanie że
> funkcja generyczna jest do dupy bo może przez nią przelecieć wyjątek
> jest absurdalne.

A kod obiektowy, w którym jest milion nieprzetestowanych rozgałęzień jest OK?

> Oczywiscie że da się obronić, w końcu skoro nie można uzywać normalnych
> technik programowania, jak wyjątki, to przeciez lepiej je koślawo
> zaemulować.

Ale ja uważam, że tam nie ma emulacji wyjątków. To jest inny mechanizm, zaaplikowany
w innym celu. Dlatego da się go obronić, chociaż oczywiście przyznaję, że
stylistycznie jest słaby.

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