On 09/05/2019 08:04, Maciej Sobczak wrote:
> Myślałem, że narzekamy na standard kodowania.

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.

> Zakaz używania wyjątków jest dosyć uniwersalny, niezależny od języka.
>>> Często sprowadza się to do pokazania użytkownikowi komunikatu o błędzie.
>> Nie wiem co to znaczy "często", ale u mnie raczej nie.>
> Interesujące. Ale to może (!) oznaczać, że obsługujesz wyjątki relatywnie blisko
ich wystąpienia.

Może, ale może też oznaczać że nie mam wyświetlacza i wiem po co je rzucam.

>> return a() && b() && c() && d() ... ;
>> To jest emulacja wyjątku w środowisku gdzie wyjątków ma nie być. Wyszło
>> jak zwykle. Parcie na systemy ograniczone wcale nie generuje lepszego
>> jakościowo kodu, co najwyżej generuje kod który lepiej ogarnia się
>> formalną weryfikacją a i to jest mocno naciągane.
> 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. Ba, wymaga się pokrycia nie tylko
ściezki wykonywania kodu, ale np. zbioru wartości danych zmiennych.

Jeśli masz kilkaset tyś lini kodu to nie jest mozliwe pokrycie go w 100%
bo bywa że liczba stanów wejściwych i ich kobinacji przekracza zdrowy
rozsądek. 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.

> Jeżeli są wyjątki, to tych ścieżek nawet nie widać

Mało kto patzy na kod. Do testowania pokrycia stosuje się automatykę.
Ona widzi wyjątki tak samo jak logjmp.

> a rozstrzygnięcie automatyczne ile ich jest i gdzie może wymagać dostępu do całego
kodu i nawet wtedy może być nierealne.

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. O
to tu chodzi: przedstawiony przykład przez Wojtka jest kompletnie
pozbawiony sensu, funkcje generyczne nigdy, przenigdy, nie powinny
zajmować się sytuacjami zwiazanymi ze światem zewnątrznym a już na pewno
nie obsługiwać cudze sideeffecty.

Nie stosuje wyjątków w praktyce. Ale stosuje dość intensywne testowanie
w praktyce. Gdybym miał tam dorzucić wyjątki jakoś niespecjalnie by mnie
to zmartwiło, co najwyżej powiększyło zbiór testów.

> Natomiast użycie iloczynu logicznego tak jak powyżej, chociaż wątpliwe
stylistycznie, jest jednak lokalne
>- tzn. analizę wszystkich ścieżek da się zrobić w ramach tylko tego
wyrażenia. Wtedy znacznie łatwiej spełnić wymaganie pokrycia testami.

Znowu Cie zmartwie: możesz pokryć tą generyczną funkcję testami w 100% a
i tak ktoś rzuci wyjątkiem który przez nią przeleci inną ścieżką,
podobnie scheduler preemptive może zmienić stan globalny albo meteoryt z
Neptuna puknąć w serwer. Ogólnie można zbadać *wszystkie* ściezki, ale
obawiam się że w praktyce to jest tylko akademicki pogląd, w przemyśle
nawet w aplikacjach do latania stosuje się śmiesze liczby w rodzaju 99%
itp. które mają związek z realnym poglądem na świat i doświadczeniem z
faktycznymi możliwościami ogarniania kodu przez białko.

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

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.

> Dlatego nie zgadzam się z określeniem "wyszło jak zwykle". Ten przykład da się
obronić. Stylistycznie słaby (subiektywnie), ale broni się na poziomie procesu.

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ć. Tak samo jak miszczofie C żałośnie emulują RAII i uważają to
za punkt honoru.

do góry

On 09/05/2019 08:21, Maciej Sobczak wrote:
>> Ariane pokazało że wybranie Ady nie powoduje że ludzie piszą kod
>> bezpiecznie, dalej pisali w asemblerze. Nie wybór języka jest istotny
>> tylko programisty.
>
> Też nie. Tzn. programiści lubią wierzyć w swoją wyjątkowość, ale przedstawione
przez Ciebie przykłady (Ariane, Toyota, Boeing)
> akurat wskazują na błędy w zarządzaniu i w wymaganiach.

Oczywiście, ja tylko odczarowuje durny pogląd "weźmy Adę, będzie
bezpiecznie". Bez ludzi majcych pojęcie o bezpieczeństwie nigdzie się z
tym nie dojdzie a w spełnianiu wymogów akurat hackerzy są bardzo dobrzy
na co przykłądem jest to że jednak dali radę w Ariane spełnic wymogi.

> Procesy jakościowe (o ile są przestrzegane) w ogóle nie zakładają, że programista
będzie perfekcyjny.
> Wręcz przeciwnie - założenie jest właśnie takie, że programista spieprzy wszystko,
co się da.

Ciesze się że się zgadzamy.

> Jakość wynika z procesów integralnych (z weryfikacji) a nie z deweloperskich.
Pytanie, czy takie procesy integralne są. Problem w tym, że łatwo z nich zrezygnować.

Tu się nie zgadzam. Można poprawnie zweryfikować dowolną kupę. Jakośc
developerki nie ma wpływu wprost na magiczne 100% ale ma duży wpływ na
obniżanie tego 100% do "no, szefie, nie damy rady 80%, mozemy ze 70% i
tyle bo Steve spier... i nikt nie wie jak to działa". Wymogi nie są z
betonu i dziwnym trafem potrafią sobie pływać w trakcie procesu produkcji.

>> Wybrali hackerów, mają kupę a nie bezpieczny kod bez
>> względu na koszerność języka.
> Wybór języka wpływa na to, jak łatwo jest coś spieprzyć.

Więc w C++ z roku na rok coraz trudniej spieprzyć. Oczywiście za
wyjątkiem reszty świata która używa MISRA i dalej uważa że nie wymyślono
nic bezpieczniejszego niż ręczną emulacje C++ w C.

> A ponieważ zakładamy, że programista spieprzy wszystko co może, to wybór języka
jest ważny. Żeby mógł spieprzyć jak najmniej.

A mimo to spieprzył. Ariane zdetonowała z powodu używania bezpiecznego
języka w niebezpieczny sposób. Czekamy na nastepny język o śmiesznej
nazwie gdzie będzie jeszcze więćej bezstanowości, korutyn, monad i całej
masy innych niezwykle przydatnych rzeczy do pisania niebezpiecznego kodu
w asemblerze. Go, Dart, Kotlin, TypeScript. Co tam ostatnio wymyślili
bezpieczniejszego bo od tygodnia nie zaglądałem na weba?

>>> A co jeśli wyjątek leci z miejsca, o którym wierzyłeś, że nigdy nie poleci
>>> i jednak dostajesz terminate?
>> To wykrywam to w unit testach i poprawiam buga.
> Unit testy nie wykrywają wyjątków. Chyba że mamy inne rozumienie tego terminu.

ASSERT_THROW. ASSERT_NO_THROW. Całkiem fajnie wykrywają.

>> A co sie stanie jak w ten kod trafi meteoryt z Neptuna? Jesteś na to
>> przygotowany?
> Jeśli takie są wymagania, to powinien być.

Więc jesli mógłbym prosić, przygotuj swoją funkcję na obsługę wyjątków.
We wszystkich nastu miejscach. Zabawmy się w taki wymóg. Potem łatwo
udowodnimy że std::vector pisali dyletanci bo przecież nie uwględnili że
z konstruktora kopiującego element może wylecieć wyjątek i zamkniemy
narzekanie o C++ konkluzją że jest do dupy i dlatego uzywa się MISRA-C
gdzie wszystko jest do dupy ale weryfikowalnej formalnie dupy a taka
jest znacząco lepsza.

do góry

On Thursday, May 9, 2019 at 11:32:28 AM UTC+2, Roman Tyczka wrote:
> On Tue, 7 May 2019 12:15:04 -0700 (PDT), Wojciech Muła wrote:
>
> > Zadanie dla chętnych: w ilu miejscach może tu polecieć wyjątek?
> > Type1 i Type2 to jakieś klasy dostarczone przez użytkownika,
> > nic o nich nie wiemy.
> >
> > Type1 fun(Type2 a, Type2 b)
> > {
> > if (a.get_value() > b.get_value()) {
> > return a.get_foo();
> > }
> >
> > return a.get_bar() + b.get_foo();
> > }
> >
> > w.
>
> Ja tak z ciekawości, bo napisałeś dalej, że jest tych miejsc 13, czy
> mógłbyś je wskazać? Nie programuję w C++, więc widzę tylko możliwość
> wysypki w wywołaniach metod (zarówno w nich samych jak i na ich braku czyli
> nilu). Ale z tego i tak nie wyjdzie aż 13. Czy masz tu na myśli jeszcze
> przeciążanie operatorów? Co jeszcze?

To czego nie zauważyłeś na pierwszy rzut oka to niejawne konwersje.
Np. get_bar może zwrócić instancję klasy Kotek, ale operator dodawania
jest zdefiniowany dla Pieska --- i jeśli Pieska da się utworzyć
z Kotka, to mamy dwa konstruktory konwertujące, które oczywiście mogą
rzucić wyjątki. Ponadto argumenty są przekazywane przez kopie, więc
wołany jest konstruktor kopiujący Type1, który potencjalnie może
coś rzucić. Tak samo wyniki zwracane mogą być typów konwertowalnych
do Type2 i przed 'return' będzie konwersja, które może się nie powieść.

C++ trochę ten problem rozwiązał przez jawne zabronienie niejawnych
konwersji :) (słówko explicit), ale to musi być wyrażone wprost
w programie.

w.

do góry

> 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

do góry

> Oczywiście, ja tylko odczarowuje durny pogląd "weźmy Adę, będzie
> bezpiecznie".

Ale nie ma takiego poglądu. Jest inny: potrzeba, żeby było jak najbezpieczniej, więc
na każdym kroku podejmijmy takie decyzje, które zwiększają nasze szanse na bezpieczny
efekt. Wybór języka jest jednym z wymiarów, w którym można się do tego efektu zbliżyć
lub oddalić.

To trochę jak z zapinaniem pasów w samochodzie. Albo z wyborem rodzaju pieca
gazowego. Itd.

> > Jakość wynika z procesów integralnych (z weryfikacji) a nie z deweloperskich.
Pytanie, czy takie procesy integralne są. Problem w tym, że łatwo z nich zrezygnować.
>
> Tu się nie zgadzam. Można poprawnie zweryfikować dowolną kupę.

Można, ale jeśli terminy gonią...

> Jakośc
> developerki nie ma wpływu wprost na magiczne 100% ale ma duży wpływ na
> obniżanie tego 100% do "no, szefie, nie damy rady 80%, mozemy ze 70% i
> tyle bo Steve spier... i nikt nie wie jak to działa".

Z innej perspektywy można powiedzieć, że ma wpływ na *koszt* osiągnięcia tych 100%,
jeśli i tak trzeba, żeby było 100%. Lepsza deweloperka to niższy koszt weryfikacji.

Bo są (co najmniej) dwa sposoby robienia projektów: przy założonej z góry jakości i
przy założonym z góry budżecie.

> Wymogi nie są z
> betonu i dziwnym trafem potrafią sobie pływać w trakcie procesu produkcji.

Tak. Ale wymogi jakościowe mogą być narzucone regulacjami, np. prawnymi albo
certyfikacyjnymi. Wtedy nie pływają.

> Więc w C++ z roku na rok coraz trudniej spieprzyć. Oczywiście za
> wyjątkiem reszty świata która używa MISRA i dalej uważa że nie wymyślono
> nic bezpieczniejszego niż ręczną emulacje C++ w C.

A co jest złego w MISRA-C++?

> > A ponieważ zakładamy, że programista spieprzy wszystko co może, to wybór języka
jest ważny. Żeby mógł spieprzyć jak najmniej.
>
> A mimo to spieprzył.

Może spieprzył mniej? Może gdyby spieprzył więcej, to rakietę by szlag trafił jeszcze
przed startem?

> Ariane zdetonowała z powodu używania bezpiecznego
> języka w niebezpieczny sposób.

Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.

> Czekamy na nastepny język o śmiesznej
> nazwie gdzie będzie jeszcze więćej bezstanowości, korutyn, monad i całej
> masy innych niezwykle przydatnych rzeczy

Tu się zgadzam. Ciekawe, czy Godek to czyta. :-)
Ale akurat Ada nie ma związku z żadną z tych rzeczy.

> Co tam ostatnio wymyślili
> bezpieczniejszego bo od tygodnia nie zaglądałem na weba?

Właśnie wygląda na to, że te wszystkie wynalazki są zwykle odgrzebywane z 30-letnich
letargów. W ogóle nie ma niczego nowego, to są kombinatoryczne złożenia starych
rzeczy.

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

> Więc jesli mógłbym prosić, przygotuj swoją funkcję na obsługę wyjątków.

Jest zakaz wyjątków. Właśnie po to, żebym nie musiał przygotowywać.

> Potem łatwo
> udowodnimy że std::vector pisali dyletanci

Nie zgadzam się. std::vector to bardzo dobra klasa. Po prostu nie dla tej niszy.

> i zamkniemy
> narzekanie o C++ konkluzją że jest do dupy i dlatego uzywa się MISRA-C
> gdzie wszystko jest do dupy ale weryfikowalnej formalnie dupy a taka
> jest znacząco lepsza.

Zależnie od potrzeb, może tak właśnie być. I nie widzę w tym nic złego. Tzn.
wolałbym, żeby było jeszcze lepiej, ale jeśli jest tylko tak jak może być, to niech
tak będzie.

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

do góry

On 10/05/2019 08:03, Maciej Sobczak wrote:
>> 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.

O tym piszę od początku jako elemencie niezbędnym obok bezpiecznego 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"?

Taki który jest na tyle typowy że produkuje się do niego bardzo, ale to
bardzo drogie narzędzia do kontrolowania procesu produkcji. Zacznij od
pojęcia "test plan".

https://en.wikipedia.org/wiki/Test_plan

> Bo w konteście całej ludzkiej aktywności programistycznej, w ogóle wymaganie
weryfikacji czegokolwiek jest niszowe.

Jeśli to coś miga diodą to masz rację. Ale jak już steruje czymkolwiek
to przegapiłeś rewolucję. Nie wejdziesz na rynek aplikacji krytycznych
bez bardzo rozbudowanego mechanizmu weryfikacji który sam podlega
regorystycznej weryfikacji.

> A jak jesteśmy w niszach, to trudno mówić o "typowym systemie".

Typowy system critical safe. Nikt tu nie mówi o pisaniu migania diodą i
narzekania że wyjątki są do tego kiepskie.

> W niszach są standardy i procesy. Nie spotkałem wymagań w procentach pokrycia.

Poczytaj o testplanach w okolicy pojęcia IpCore i programowania hardware.

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

Tak. Np. ze wszystkich 2^32 adresów IP przetestowaliśmy 5% i wydają się
działać w duperelowatym kawałku kodu do migania diodą jak przyjdzie
pakiet broadcast.

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

Nie, weryfikacja powstaje *zanim* napiszesz kod. Tylko że ludzie piszący
wymagania wiedzą że coś jest nierealne do osiągnięcia jak 100% pokrycia
itd itp. Zarządza się ryzykiem.

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

Zorientował się przed napisaniem kodu. Oszacował ryzyko, w każdym
punkcie systemu inaczej. Ryzyko mikrokernela jest wysokie i tam stopień
pokrycia i wymagania co do jakosci są wyższe. Dla sterownika wentylatora
nie są tak wyśrubowane a do sterownika poświetlenia klawiatury są niskie.

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

Nie dalej nie czaisz. Obecnie pisanie systemów krytycznych podlega pod
bardzo restrykcyjne zasady. W nich samego pisania jest mało, znacznie
więcej jest dokumentowania wymagań, śledzenia zmian, akceptacji,
odpowiedzialności itp itd tylko że w przeciwieństwie do banków tutaj
całosć procesu jest automatyzowana w miarę możliwości w całości.

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

To trzeba zmienić tool.

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

Mało porawdopodobne. Standardy tego typu powstają kiedy obecni
użytkownicy szczali jeszcze w pieluchy. Wystarczy zauważyć że w ciągu 10
lat projkekt LLVM z pomysłu stał się praktycznie kombajnem do
weryfikacji i to zaskakującej jakości jak na projekt "akademicki".

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

I źródłowego, i wynikowego i każdego innego który ma wpływ na
bezpieczeństwo.

Przykładowo narzędzia do weryfikacji potrafią powiązać dowolną linijkę
kodu źródłowego z wymaganiem formalnym i śledzić zmiany.

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

Przypuszczam że Ariane miała zakaz przepełniania zmiennych. Nawet może
ktoś pogroził paluszkiem.

>> 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%?

Bo wymaga to 99% czasu więcej? Szacujący ryzyko ocenia na ile chce mieć
system działający vs system w wiecznej fazie produkcji.

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

Ale co to ma wspólnego z fukcją generyczną?

Kod obiektowy w którym jest milion nieprzetestowancyh rozgałęzień ma
milion miejsc do poprawienia na weryfikacji. Zakasujesz rękawy i
pokrywasz albo masz w zespole człowieka który nie dopuści do takiego
dziadostwa. Ale spokojnie, autoamty do weryfikacji też nie odpuszczą a
na samym końcu ktoś się pod tym podpisuje i to jego złapią za jaja w
razie wypadku.

do góry

On 10/05/2019 08:21, Maciej Sobczak wrote:
> A co jest złego w MISRA-C++?

Nikt go nie używa. Zacytuje jednego z developerów MICRA-C: "Znowu te
pedały coś wymyśliły". Po prostu jest niekoszerny. Najbardziej widać to
w automatyce przemysłowej i kontrolerach. Mimo że nawet 8-bitowy
procesor skorzystał by z kodu pisanego w C++ to typowy developer uC
nawet go kijem nie ruszy bo jednak nic lepszego niż void* nie wymyślono.

>>> A ponieważ zakładamy, że programista spieprzy wszystko co może, to wybór języka
jest ważny. Żeby mógł spieprzyć jak najmniej.
>> A mimo to spieprzył.
> Może spieprzył mniej? Może gdyby spieprzył więcej, to rakietę by szlag trafił
jeszcze przed startem?

Może. Problem w tym że to nie ma znaczenia. 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.

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.

Tutaj nadziubdziali żałosny asm.

Albo core review składał się z takich samych hackerów jak ten miszczu
albo też code review nie było i cała ta Ada to pic na wodę. I nie
mówiłbym tego gdyby nie to że przez te ostatnie naście lat widziałem
troszkę kodu "bezpiecznego" i funta kłaków bym za wiele kawałków nie
dał, to po prostu dobrze udokumentowane i przetestowane g...

>> Ariane zdetonowała z powodu używania bezpiecznego
>> języka w niebezpieczny sposób.
> Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.

Tak. Na przykład Verilog. Język z wbudowaną wadą projektową i
najbardziej rozbudowanym systemem weryfikacji do zastosowań krytycznych.
Dzień jak codzień w IT.

>> Czekamy na nastepny język o śmiesznej
>> nazwie gdzie będzie jeszcze więćej bezstanowości, korutyn, monad i całej
>> masy innych niezwykle przydatnych rzeczy
> Tu się zgadzam. Ciekawe, czy Godek to czyta. :-)
> Ale akurat Ada nie ma związku z żadną z tych rzeczy.

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

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

>> Więc jesli mógłbym prosić, przygotuj swoją funkcję na obsługę wyjątków.
> Jest zakaz wyjątków. Właśnie po to, żebym nie musiał przygotowywać.

No ale to nie udowania tezy że rzucanie wyjątku przez generyka jest
bezpieczne czy niebezpieczne. To tylko chowanie głowy w piasek z braku
argumentacji.

Powtarzam, wyjątek czy nie, nie jest kwestią funkcji generycznych jego
obsługa. Jakiekolwiek kombinowanie w tym temacie to błąd projektowy.

do góry

> > Co to jest "typowy system"?
>
> Taki który jest na tyle typowy że produkuje się do niego bardzo, ale to
> bardzo drogie narzędzia

Ciekawy pogląd, z którym się nie zgodzam. Typowy system (ogólnie: produkt) to taki,
który przez swoją typowość znajduje się w mainstreamie, gdzie akurat podaż narzędzi
jest największa. W rzeczywistości tak duża, że można z góry założyć jako normę, że
wszystkie narzędzia są darmowe. Od edytorów przez kompilatory po systemy kontroli
wersji aż po narzędzia do zarządzania zespołem. Wszystko za friko. To jest teraz
typowe.

Drogie narzędzia robi się wtedy, gdy ktoś nie ma wyjścia i musi je kupić. Bo w
szczególności nikomu nie chce się ich robić. To są z natury nietypowe (niszowe)
rzeczy.

> Zacznij od
> pojęcia "test plan".
>
> https://en.wikipedia.org/wiki/Test_plan

No i co z nim? Na tej stronie ani razu nie pojawia się słowo "expensive". Ba, nawet
słowo "tool" się nie pojawia, więc chyba w ogóle żadnych narzędzi nie trzeba mieć.

> Nie wejdziesz na rynek aplikacji krytycznych
> bez bardzo rozbudowanego mechanizmu weryfikacji który sam podlega
> regorystycznej weryfikacji.

Tak.

> > A jak jesteśmy w niszach, to trudno mówić o "typowym systemie".
>
> Typowy system critical safe.

Właśnie o to pytam. Bo w moim rozumieniu nie ma czegoś takiego. Każdy jest nietypowy.

> Poczytaj o testplanach w okolicy pojęcia IpCore i programowania hardware.

Gdzie mogę o tym poczytać?

> Tylko że ludzie piszący
> wymagania wiedzą że coś jest nierealne do osiągnięcia jak 100% pokrycia
> itd itp. Zarządza się ryzykiem.

Nie w sotfwarze. W HW chyba obowiązuje kultura myślenia w procentach, bo tak się
zarządza ryzykiem w odniesieniu do systemów fizycznych (np. mechanicznych), gdzie
występują przypadkowe błędy produkcji, degradacja (zmęczenie) materiału, itd. Tak
można też liczyć hardware w sensie hardware. Natomiast software nie ma takich zjawisk
i dlatego zarządzanie ryzykiem w ten sam sposób nie ma sensu. Ludzie, którzy
projektują hardware jadą jeszcze na tej kulturze wyniesionej z systemów fizycznych,
ale w branży pojawiło się już zrozumienie, że VHDL czy inny Verilog to software a nie
hardware i pojwinno się to robić według procesów software'owych a nie hardware'owych.
Czyli programowanie hardware'u przy użyciu procentów to ściema.

Bo alternatywą jest konsekwentne przeniesienie myślenia procentowego na software a to
by był koniec systemów krytycznych w ogóle.

> Zorientował się przed napisaniem kodu. Oszacował ryzyko, w każdym
> punkcie systemu inaczej.

A na jakiej podstawie oszacował?

> Nie dalej nie czaisz. Obecnie pisanie systemów krytycznych podlega pod
> bardzo restrykcyjne zasady.

W procentach? To się nie rozumiemy.

> W nich samego pisania jest mało, znacznie
> więcej jest dokumentowania wymagań, śledzenia zmian, akceptacji,
> odpowiedzialności itp itd tylko że w przeciwieństwie do banków tutaj
> całosć procesu jest automatyzowana w miarę możliwości w całości.

Niestety nie. Bo te restrykcyjne zasady dotyczą też narzędzi i w wielu przypadkach
nie opłaca się automatyzować (!), bo weryfikacja automatu też jest kosztem, w dodatku
przez management traktowanym jako uboczny - co jest zrozumiałe, klient płaci za
produkt, a nie za automat użyty przy tworzeniu tego produktu.
I to właśnie dlatego pisania jest mało. Bo gdyby dało się wszystko zautomatyzować, to
programiści by tylko pisali a cała reszta by się działa automatycznie. Mała ilość
pisania jest właśnie miarą tego, jak bardzo ta branża jest niezautomatyzowana.

> > 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.
>
> To trzeba zmienić tool.

Na jaki? Może tam w Ameryce nie wiedzą?

> > Problem w tym, że nadal jest "not adequate". I bardzo możliwe, że zawsze tak
będzie.
>
> Mało porawdopodobne. Standardy tego typu powstają kiedy obecni
> użytkownicy szczali jeszcze w pieluchy. Wystarczy zauważyć że w ciągu 10
> lat projkekt LLVM z pomysłu stał się praktycznie kombajnem do
> weryfikacji i to zaskakującej jakości jak na projekt "akademicki".

I nadal jest to "not adequate". Bo kombajnem to on sobie może być, ale restrykjcyjne
reguły, o których sam wspomniałeś, wykluczają go z użycia.

> Przypuszczam że Ariane miała zakaz przepełniania zmiennych. Nawet może
> ktoś pogroził paluszkiem.

Zapewne. Ale zakaz rzucania wyjątków jest łatwiejszy, bo można to sprawdzić grepem.

> > A dlaczego nie dało się pokryć tego brakującego 1%?
>
> Bo wymaga to 99% czasu więcej?

Własnie pytam, dlaczego. Cóż takiego tam jest, że wymaga 99% czasu więcej?

> Szacujący ryzyko ocenia na ile chce mieć
> system działający vs system w wiecznej fazie produkcji.

Ale regulacje prawne nie określają, na ile działający ma być system. Zwłaszcza
software'owy, gdzie nie można się tłumaczyć wadami materiałowymi, albo zmęczeniem
struktury.

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

do góry

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

do góry

On 2019-05-13 08:40, Maciej Sobczak wrote:
>>> 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ń.uktu dec
>> 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.

Nie od czapy, ale sedno sprawy.
Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
fachowiec.
To, że branża IT o tym dawno zapomniała i wciąż udaje (wzorem prof.
Marciniaka), że każdego dobrego fachowca można zastąpić skonczoną
liczbą studentów, to jej problem główny. Jeśli tego nie zmieni
(nie wróci do korzeni) to tysiace MISR czy auto-weryfikatorów nie
pomoże.
Branża IT zapomniałą nawet jak sie "tworzy" fachowca:
Wpierw uczeń (dobrych kilka lat), czeladnik (dobrych kilka lat),
potem pracownik (ale bez możliwości spieprzenia - tam gdzie można
zepsuć wciaż dzała i wykonuje mistrz), dopiero z czasem (wciąż
pod nadzorem i przyzwoleniem mistrza - bo to on wie co jest
"krytyczne" a co nie) roboty "rynkowe". Po wielu latach dopiero
można założyć "własną kużnię".
A w IT? nawet uC?
Dwa lata po studiach to już Experienced Senior Developer ;)

AK

do góry