Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32516 > unrolled thread

Ada Tutorial - w Instytucie Lotnictwa

Back to article view | Back to pl.comp.programming

Contents

  Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-04-17 10:41 -0700
    Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-17 20:43 +0200
      Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-04-18 06:01 -0700
        Re: Ada Tutorial - w Instytucie Lotnictwa Sebastian Biały <heby@poczta.onet.pl> - 2019-04-19 19:24 +0200
          Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-20 13:46 +0200
            Re: Ada Tutorial - w Instytucie Lotnictwa Sebastian Biały <heby@poczta.onet.pl> - 2019-04-20 15:02 +0200
              Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-20 16:20 +0200
                Re: Ada Tutorial - w Instytucie Lotnictwa slawek <x.y@org.org> - 2019-04-23 21:27 +0200
                  Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-04-24 00:11 -0700
              Re: Ada Tutorial - w Instytucie Lotnictwa Borneq <borneq@antyspam.hidden.pl> - 2019-08-04 18:11 +0200
        Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-20 13:43 +0200
          Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-04-22 11:51 -0700
      Re: Ada Tutorial - w Instytucie Lotnictwa Wojciech Muła <wojtek.mula@gmail.com> - 2019-05-07 12:15 -0700
        Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-05-07 21:38 +0200
        Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-07 22:52 +0200
          Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-07 22:54 -0700
            Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-08 19:31 +0200
              Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-08 23:04 -0700
                Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-09 18:19 +0200
                  Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-09 23:03 -0700
                    Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-10 20:33 +0200
                      Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-12 23:29 -0700
          Re: Ada Tutorial - w Instytucie Lotnictwa Wojciech Muła <wojtek.mula@gmail.com> - 2019-05-08 06:32 -0700
            Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-08 19:51 +0200
              Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-08 23:21 -0700
                Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-09 18:34 +0200
                  Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-09 23:21 -0700
                    Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-10 21:00 +0200
                      Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-12 23:40 -0700
                        Re: Ada Tutorial - w Instytucie Lotnictwa AK <nobody@nowhere.net> - 2019-05-13 09:27 +0200
                          Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-05-13 03:05 -0700
                            Re: Ada Tutorial - w Instytucie Lotnictwa AK <nobody@nowhere.net> - 2019-05-14 00:53 +0200
                              Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-05-13 23:51 -0700
                                Re: Ada Tutorial - w Instytucie Lotnictwa AK <nobody@nowhere.net> - 2019-05-15 21:25 +0200
                                  Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-05-15 23:55 -0700
                          Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-14 00:55 -0700
                            Re: Ada Tutorial - w Instytucie Lotnictwa Adam M <amorawski@magna-power.com> - 2019-05-14 06:25 -0700
                              Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-14 23:09 -0700
        Re: Ada Tutorial - w Instytucie Lotnictwa Roman Tyczka <noemail@because.no> - 2019-05-09 11:32 +0200
          Re: Ada Tutorial - w Instytucie Lotnictwa Wojciech Muła <wojtek.mula@gmail.com> - 2019-05-09 10:29 -0700

Page 1 of 2  [1] 2  Next page →

#32516 — Ada Tutorial - w Instytucie Lotnictwa

Cześć,

W drugim tygodniu czerwca w Instytucie Lotnictwa w Warszawie będzie miała miejsce konferencja Ada-Europe 2019:

http://ae2019.edc.pl/

Było już kilka komunikatów w tej sprawie na grupie, ale chciałem zwrócić uwagę grupowiczów na jeden szczegół:

W pierwszym dniu konferencji (11 czerwca, wtorek) odbędą się dwa równoległe tutoriale (http://ae2019.edc.pl/tutorials.html):

- T1: Controlling I/O Devices with Ada, oraz

- T2: An introduction to Ada.

Obydwa (i zwłaszcza ten drugi) mogą zainteresować osoby, które są ciekawe języka a nie znalazły do tej pory impulsu, żeby spróbować.
Całodniowe tutoriale poprowadzą bardzo doświadczeni fachowcy, po angielsku.

Koszt to 40 EUR. Słownie: cztery eurodychy.

Rejestracja tutaj: https://registration.ada-europe.org/

W razie pytań zapraszam.

-- 
Maciej Sobczak

[toc] | [next] | [standalone]

#32517

> W pierwszym dniu konferencji (11 czerwca, wtorek) odbędą się dwa równoległe tutoriale (http://ae2019.edc.pl/tutorials.html):
> 
> - T1: Controlling I/O Devices with Ada, oraz
> 
> - T2: An introduction to Ada.
> 
> Obydwa (i zwłaszcza ten drugi) mogą zainteresować osoby, które są ciekawe języka a nie znalazły do tej pory impulsu, żeby spróbować.

Miałem na studiach prawie 20 lat temu. Wnioski: szkoda sobie zawracać 
głowę - atrakcyjność Ady jest mniej więcej taka jak syrenki-kabrio w 
dzisiejszych czasach... - nie ten klimat i nie te czasy...
Nawet w Szap (ang. Usa) w najnowszym swym wynalazku F-35 wszystko 
zakodowali w C++ ... Najwyraźniej uznali że Ada to dziadostwo i ogólnie 
do nauki tego nie ma chętnych...
Inna sprawa, że F-35-coding-rules.pdf wprowadza takie ograniczenia, że z 
tego C++ zostaje może 25% przez co programowanie zgodnie z tymi 
zaleceniami jest bardziej prymitywne niż w latach 90 XXw (czyli z przed 
standaryzacji C++). Widać, że ktoś bardzo lubił Ada-ę i pomyślał, że w 
zasadzie można by tak samo programować w C++.

[toc] | [prev] | [next] | [standalone]

#32518

> Miałem na studiach prawie 20 lat temu.

No właśnie - jedną z głównych prezentacji (http://ae2019.edc.pl/keynotes.html) będzie "A 2020 View of Ada". Być może będzie to inna perspektywa, niż Twoje wspomnienia ze studiów.

> nie ten klimat i nie te czasy...

A konkretnie jaki klimat i jakie czasy? Przykładowo, Python zaczął swoją historię 29 lat temu. To nawet wcześniej, niż Twoje studia.

Po czym poznać, że klimat i czasy są właściwe?

> Nawet w Szap (ang. Usa) w najnowszym swym wynalazku F-35

"F-35 development started in 1992" (z Wikipedii).

Czyli wcześniej, niż Twoje studia. Dużo wcześniej. To zdecydowanie nie jest najnowszy wynalazek.

> wszystko 
> zakodowali w C++ ... Najwyraźniej uznali że Ada to dziadostwo

F-35 jest chyba najbardziej krytykowanym współczesnym samolotem.

"critics argued that the plane was "plagued with design flaws""

"The program received considerable criticism for cost overruns during development"

Czyli to chyba nie był najlepszy przykład. :-)

> Inna sprawa, że F-35-coding-rules.pdf wprowadza takie ograniczenia, że z 
> tego C++ zostaje może 25%

I to tylko dlatego, że to nie jest projekt cywilny. Bo gdyby był cywilny, to by zostało 5%.

> Widać, że ktoś bardzo lubił Ada-ę i pomyślał, że w 
> zasadzie można by tak samo programować w C++.

To nie wina Ady, tylko standardów lotniczych. Bo Ady też używa się tylko kilka procent. Pełna Ada to zupełnie inne zjawisko - ale o tym najlepiej dowiedzieć się na tutorialu (albo na całej konferencji).

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

[toc] | [prev] | [next] | [standalone]

#32519

On 18/04/2019 15:01, Maciej Sobczak wrote:
> F-35 jest chyba najbardziej krytykowanym współczesnym samolotem.
> "critics argued that the plane was "plagued with design flaws""
> "The program received considerable criticism for cost overruns during development"
> Czyli to chyba nie był najlepszy przykład. :-)

Kontrprzykład to Ariane-5 do której jako programistów zatrudnili 
hackerów dłubiących na poziomie bitów i całe to bezpieczeństwo Ady 
poszło w pizdu. Jak w większości "bezpiecznych" języków nic nie 
ogranicza przed hackerami emulującymi sobie w środku asembler.

Z chęcią bym zobaczył jakiś przykąłd porządnie zrobionego projektu w 
Adzie, ale będzie on zapewne albo akademicki i interesujacy, albo 
przemysłowy i zrobiony za pomocą jakiegoś odpowiednika MISRA czyli flaki 
z olejem.

[toc] | [prev] | [next] | [standalone]

#32521

> Jak w większości "bezpiecznych" języków nic nie 
> ogranicza przed hackerami emulującymi sobie w środku asembler.

Mógłbyś rozwinąć tą myśl?!?

[toc] | [prev] | [next] | [standalone]

#32522

On 20/04/2019 13:46, Szyk Cech wrote:
>> Jak w większości "bezpiecznych" języków nic nie ogranicza przed 
>> hackerami emulującymi sobie w środku asembler.
> Mógłbyś rozwinąć tą myśl?!?

Ależ bardzo prosto. Ariane dupneła z powodu tego że ktoś w "bezpiecznym" 
języku zrobił założenie że coś zmieci się w 16 bitach. Typowe myślenie 
asemblerowca który wszędzie widzi bajty do oszczędzenia.

Tu masz fragmenty kodu:

https://hownot2code.com/2016/09/02/a-space-error-370-million-for-an-integer-overflow/

Wygląda jak asembler wydziobany ręcznie. I tak oto bezpieczny język 
posłużył jako platforma do napisania nispoziomowego kodu do manipulacji 
liczbami w sposób błędny. Dzień jak codzień. No i jeszcze księgowi 
dorzucili swoje:

"The protection of all 7 (including BH) variables wasn’t provided 
because the maximum workload for the IRS computer was declared as 80%."

[toc] | [prev] | [next] | [standalone]

#32523

> Tu masz fragmenty kodu:
> 
> https://hownot2code.com/2016/09/02/a-space-error-370-million-for-an-integer-overflow/ 

"The erroneous module was never properly tested in the new environment – 
neither the hardware, nor the level of system integration. Therefore, 
the flaws in the development and implementation were not detected."

Czyli poleciało nieprzetestowane. To zamyka temat: błąd programisty to 
jedno, ale brak przetestowania to strategiczne partactwo firmy która to 
robiła.

Żaden kod nie powinien być udostępniany bez przejścia specjalnie 
zdefiniowanej procedury testowej (choćby wykonywanej "ręcznie"). A kod 
krytyczny zawsze powinien być obłożony testami automatycznymi.

Niestety w polskich firmach dedykowani testerzy to wciąż egzotyka. Moim 
zdaniem te firmy są skazane na wymarcie - właśnie ze względu na 
partackie podejście do procesu wytwórczego.

[toc] | [prev] | [next] | [standalone]

#32530

Problem jest znacznie bardziej. Testowanie to proteza. Czasem
 pomaga. Raczej nie szkodzi. Ale rozwiązaniem jest inne spojrzenie
 na to czym jest bug, czym jest program itd. Myśleliśmy że
 komputery będą wolne od ludzkich słabości. Ale tak nie jest.
 Musimy nauczyć się akceptować i określić co chcemy akceptować.
 Przykładowo: czy jeżeli automatyczne lądowanie F35 może zakończyć
 się śmiercią pilota to jest to ok? Dodatkowe dane:
 prawdopodobieństwo jest znacznie mniejsze niż gdy pilotuje
 człowiek - ale większe niż zero i - gdyby napisać lepiej program
 byłoby mniejsze.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#32531

W dniu wtorek, 23 kwietnia 2019 21:27:13 UTC+2 użytkownik slawek napisał:
> Problem jest znacznie bardziej. Testowanie to proteza. Czasem
>  pomaga. Raczej nie szkodzi.

?
Testowanie to proteza?!
"Zbudowaliśmy dla państwa samolot. Nie, nie przetestowaliśmy, ale w teorii wszystko powinno działać."
"Jutro oddajemy most do użytku. Nie testowaliśmy, ale mamy na miejscu inżyniera. Jak by się działo coś złego, to naprawi"

Testowanie jest integralną częścią budowy każdego systemu.

> Ale rozwiązaniem jest inne spojrzenie
>  na to czym jest bug, czym jest program itd. Myśleliśmy że
>  komputery będą wolne od ludzkich słabości. Ale tak nie jest.

?!
"Mój komputer pierdzi jak się obeżre grochu"
"Zrezygnowaliśmy z instalacji kolejnej aplikacji, bo komputer powiedział, że jest już zmęczony i chce iść spać"
"Tegoroczne wybory zostają odwołane z powodu strajku maszyn obliczeniowych"
"Komputer powiedział, że nie będzie uruchamiał aplikacji finansowych w piątek 13tego, bo to przynosi pecha"

>  Musimy nauczyć się akceptować i określić co chcemy akceptować.

Kolega opowiadał historię, jak koleżanki jego mamy z pracy korzystające z Windowsa 95 wezwały go kiedyś, bo miały problem z wyskakującym niebieskim ekranem.
Miały na ten temat różne hipotezy - że na przykład jak się przejdzie przez drzwi, to się robi niebieski ekran, albo że jak się będzie podlewało kwiat, itd.

Ludzie są aż za dobrzy w wymyślaniu nierzeczywistych przyczyn dla zjawisk.
(Dowodem na to jest istnienie wielu religii i kultów).

Rzeczywistą przyczyną problemu był WinNuke. Kolega powiedział, żeby odłączyły komputery od sieci, i wtedy problem rzeczywiście zniknął.

Tym, czego musimy się nauczyć, nie jest akceptowanie, tylko rozumienie.
Idealnie byłoby, gdyby użytkownik systemu mógł łatwo rozumieć zasady działania systemu, którego używa, i samemu móc go zmieniać.
W świecie komputerów to nie jest jakiś "utopijny ideał".

>  Przykładowo: czy jeżeli automatyczne lądowanie F35 może zakończyć
>  się śmiercią pilota to jest to ok?

Nie, to nie jest ok.

> Dodatkowe dane:
>  prawdopodobieństwo jest znacznie mniejsze niż gdy pilotuje
>  człowiek - ale większe niż zero i - gdyby napisać lepiej program
>  byłoby mniejsze.

I gdyby go dobrze wytestować, żeby przynajmniej znać ryzyko.

[toc] | [prev] | [next] | [standalone]

#32790

On 4/20/19 3:02 PM, Sebastian Biały wrote:
> Ależ bardzo prosto. Ariane dupneła z powodu tego że ktoś w "bezpiecznym" 
> języku zrobił założenie że coś zmieci się w 16 bitach. Typowe myślenie 
> asemblerowca który wszędzie widzi bajty do oszczędzenia.

Bezpieczeństwo języka ma znaczenie,
wyobraźmy sobie że rakieta mam wykonać jakiś manewr a tu wyskakuje błąd 
"method NNN not found" bo oprogramowanie zostało napisane w 
interpretowanym Pythonie ;-)
albo łazik ląduje na Księżycu, a tu włączyła się aktualizacja Windows.:))
W skromniejszym przypadku: cenne są milisekundy a tu włącza się Garbage 
Collector.

W takim Rust kompilator robi wiele sprawdzeń za nas.

[toc] | [prev] | [next] | [standalone]

#32520

>> nie ten klimat i nie te czasy...
> 
> Po czym poznać, że klimat i czasy są właściwe?

Tu poruszamy 2 sprawy:
1. Klimat - wspomniana "Syrenka kabrio" nie sprawdzi się u nas - nie ten 
klimat (często pada i mamy tu zimy).

2. Właściwe czasy - to szerszy temat:
- Model obiektowy Ady:
Ze strony: 
https://learn.adacore.com/courses/intro-to-ada/chapters/object_oriented_programming.html

Rzuciłem na to okiem i tak jak prawie 20 lat temu było i teraz jest to 
straszne...

- Czy mamy dla Ady:
	- środowiska programowania z dynamicznym sprawdzaniem poprawności kodu 
(jak w Qt Creator)
	- środowiska programowania z możliwością uruchamiania programu ze 
śledzeniem (debuger)
	- profiler (liczba wywołań funkcji i wykrywanie wycieków pamięci)
	- bibliotekę Gui (co np. z OpenGl - da się używać?)
	- wsparcie dla internacjonalizacji Gui
	- czy można w Ada pisać jednocześnie na wiele systemów operacyjnych 
(przenośnie)
	- czy Ada oferuje wyjątki (do zgłaszania błędów)
	- czy można dokumentować kod w komentarzach (Doxygen lub podobne)

Moim zdaniem to wszystko musi być jeśli chcemy zająć się programowaniem 
na poważnie i bez przyjmowania jakichś sztucznych ograniczeń. Przejście 
na inny język to nie tylko kwestia składni - wiele zależy od wsparcia w 
obszarach jakie wymieniłem. I tak się składa, że C++ ma to wszystko (i 
więcej). To dla tego język D nie może "zaistnieć" bo po prostu jest 
słabo wspierany, a nie to że jest zły (choć największe zło w nim polega 
na tym, że nie ma wielodziedziczenia).

Ja przy tym wszystkim zupełnie nie wiem gdzie można by pracować w 
Trójmieście (w którym mieszkam) profesjonalnie programując w Ada. Już 
będąc programistą C++ mam problem ze znalezieniem pracy... Jednak się 
tym nie zrażam, bo w C++ widzę rozsądek (wydajność, możliwości, 
składania i wsparcie) i potencjał. Wszystkie inne języki konkurencyjne 
nie mają któregoś z tych 4 zdroworozsądkowych parametrów lub nie mają 
potencjału.

Nie zrozum mnie źle: to dobrze, że jest wiele języków programowania. 
Jednak trzeba wiedzieć co one mogą i do czego ew. je stosować.
Obecnie jest tak, że do krytycznych zadań przy zaczynaniu nowego 
projektu i przy NORMALNYM podejmowaniu decyzji (opartym na doświadczeniu 
a nie na polityce czy tradycjach) nadaje się tylko C++. I faktycznie 
najważniejsze aplikacje jakich na co dzień się używa są pisane w C++ - 
to nie przypadek. A pozostałe języki w 90% też są kodowane w C++.

Ada stosowana jest w branży zbrojeniowej i może można na tym zarobić. 
Jednak ja zupełnie nie widzę jej przewagi nad C++, a wręcz przeciwnie 
widzę brak kompatybilności jeśli chodzi o popularne narzędzia i dostępne 
biblioteki (C i C++).

[toc] | [prev] | [next] | [standalone]

#32527

> 2. Właściwe czasy - to szerszy temat:
> - Model obiektowy Ady:
> Ze strony: 
> https://learn.adacore.com/courses/intro-to-ada/chapters/object_oriented_programming.html
> 
> Rzuciłem na to okiem i tak jak prawie 20 lat temu było i teraz jest to 
> straszne...

Niezupełnie, bo akurat w ciągu tych 20 lat wprowadzono składnię, której 20 lat temu nie było.
Niemniej, faktem jest, że obiektowość w Adzie wygląda trochę inaczej, niż np. w Javie. Czy to gorzej czy lepiej, zdania są podzielone.

> - Czy mamy dla Ady:
> 	- środowiska programowania z dynamicznym sprawdzaniem poprawności kodu

Z dynamicznym? A po co z dynamicznym?
Do statycznego jest np. to:

https://www.adacore.com/codepeer

albo to:

http://www.adalog.fr/en/adacontrol.html

albo choćby kompilator w trybie sprawdzania poprawności (w odróżnieniu od trybu translacji).
 
> 	- środowiska programowania z możliwością uruchamiania programu ze 
> śledzeniem (debuger)

Kilka. Współcześnie rozwijany to GNAT Programming Studio:

https://www.adacore.com/gnatpro/toolsuite/gps

> 	- profiler (liczba wywołań funkcji i wykrywanie wycieków pamięci)

Ogólnie, GNAT oparty jest o GCC, więc wykorzystuje ten sam debugger, profiler i całą resztę dostępną w GCC.

> 	- bibliotekę Gui

Wszystkie poważne:

https://en.wikibooks.org/wiki/Ada_Programming/Libraries/GUI

> (co np. z OpenGl - da się używać?)

http://flyx.github.io/OpenGLAda/

> 	- wsparcie dla internacjonalizacji Gui

Przypuszczam, że razem z tymi bibliotekami powyżej.

> 	- czy można w Ada pisać jednocześnie na wiele systemów operacyjnych 
> (przenośnie)

Tak. Patrz wyżej, GNAT oparty jest o GCC.

> 	- czy Ada oferuje wyjątki (do zgłaszania błędów)

Tak, chociaż wyglądają one inaczej, niż w C++ (nie są obiektami ani wartościami).

> 	- czy można dokumentować kod w komentarzach (Doxygen lub podobne)

Czyli czy można generować dokumentację HTML z kodu na podstawie komentarzy? Pewnie można, sam kiedyś napisałem skrypt, który to robi.

> Moim zdaniem to wszystko musi być jeśli chcemy zająć się programowaniem 
> na poważnie

Nie. Na poważnie powinno być dużo więcej, zależnie od tworzonych systemów.

> Ja przy tym wszystkim zupełnie nie wiem gdzie można by pracować w 
> Trójmieście (w którym mieszkam) profesjonalnie programując w Ada.

Ja też nie wiem. Ale to nie zmienia faktu, że i tak zapraszam na tutorial. :-)

> Ada stosowana jest w branży zbrojeniowej

https://www.adacore.com/industries

> Jednak ja zupełnie nie widzę jej przewagi nad C++

Znajomość Ady będzie Twoją przewagą gdy będziesz pisał, nawet w C++.

-- 
Maciej Sobczak

[toc] | [prev] | [next] | [standalone]

#32535

On Wednesday, April 17, 2019 at 8:43:22 PM UTC+2, Szyk Cech wrote:
> Inna sprawa, że F-35-coding-rules.pdf wprowadza takie ograniczenia, że z 
> tego C++ zostaje może 25% przez co programowanie zgodnie z tymi 
> zaleceniami jest bardziej prymitywne niż w latach 90 XXw (czyli z przed 
> standaryzacji C++). Widać, że ktoś bardzo lubił Ada-ę i pomyślał, że w 
> zasadzie można by tak samo programować w C++.

Nie, ktoś znał bardzo dobrze C++ i wywalił wszystkie niebezpieczne
i błędogenne konstrukcje. C++ zachęca do pisania w stylu "write
once, debug endlessly", co się słabo sprawdza przy sterowaniu
maszyną wartą sześcio-, czy siedmiocyfrową kwotę.

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.

[toc] | [prev] | [next] | [standalone]

#32536

> Zadanie dla chętnych: w ilu miejscach może tu polecieć wyjątek?

Kogo to obchodzi? Moje (proste i sprawdzone w praktyce w programowaniu w 
C++ z Qt od 10 lat) zasady obsługi wyjątków są takie:

1. Każda klasa wyjątku dziedziczy po std::exception (tego przestrzegają 
też klasy wyjątków Qt),

2. Obstawiamy funkcję main czymś takim:

#define MAIN_CONSOLE_CATCH \
     catch(Exception& aEx)   \
     {   \
         QTextStream lErr(stderr);   \
         lErr << QObject::tr("Exception occurs! Sender: %1, Error code: 
%2\nMessage:\n%3").arg(aEx.senderName()).arg(aEx.errorCode()).arg(aEx.what()).toUtf8() 
<< endl << flush;  \
         return EXIT_FAILURE;    \
     }   \
     catch(std::exception& aEx)  \
     {   \
         QTextStream lErr(stderr);   \
         lErr << QObject::tr("Exception 
occurs!\nMessage:\n%1").arg(aEx.what()).toUtf8() << endl << flush;    \
         return EXIT_FAILURE;    \
     }   \
     catch(...)  \
     {   \
         QTextStream lErr(stderr);   \
         lErr << QObject::tr("Unknown exception occurs!") << endl << 
flush;   \
         return EXIT_FAILURE;    \
     }


3. Obstawiamy wszystkie funkcje obsługi zdarzeń
4. Obstawiamy wszystkie funkcje wątków, obie czymś takim:

#define STANDARD_CATCH \
     catch(Exception& aEx) \
     { \
         gCritical(QObject::tr("Exception occurs!\n%1").arg(aEx.what()), 
aEx.senderName(), static_cast<quint64>(aEx.errorCode())); \
     } \
     catch(std::exception& aEx) \
     { \
         gCritical(QObject::tr("Exception occurs!\n%1").arg(aEx.what()), 
QObject::tr("Unkonwn"), 
static_cast<quint64>(EnergoKodTools::eErrorCode::eUnknown)); \
     } \
     catch(...) \
     { \
         gCritical(QObject::tr("Unknown exception occurs!"), 
QObject::tr("Unkonwn"), 
static_cast<quint64>(EnergoKodTools::eErrorCode::eUnknown)); \
     }

Gdzie gCritical jest czymś takim:

inline void gCritical(QString aText, QString aSender, quint64 aErrorCode)
{
     Errors::instance()->error(aText, eErrorType::eCritical, aSender, 
aErrorCode);
     gMessage(QMessageBox::Critical, QObject::tr("Critical"), aText, 
QStringLiteral("Error: %1\nModule: %2\nCode: 
%3").arg(aText).arg(aSender).arg(aErrorCode));
}

Errors to klasa "silnik", singleton zbierania błędów (do ew. 
wyświetlenia i ew. zaraportowania).
A gMessage to:

inline void gMessage(QMessageBox::Icon aIcon, QString aShortText, 
QString aInformativeText, QString aDetailedText = QStringLiteral(""))
{
     QTextStream lErrStream(stderr);
     lErrStream << QObject::tr("%1 
%2\n%3").arg(qApp->applicationName()).arg(aShortText).arg(aInformativeText);
     if(!aDetailedText.isEmpty())
         lErrStream << endl << aDetailedText;

     QMessageBox lMessage;
     lMessage.setText(aShortText);
     lMessage.setInformativeText(aInformativeText);
     lMessage.setDetailedText(aDetailedText);
     lMessage.setIcon(aIcon);
     lMessage.exec();
}

I wtedy wszystko jest proste...

[toc] | [prev] | [next] | [standalone]

#32537

On 07/05/2019 21:15, 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();
> }

Skoro nic o nich nie wiemy to obsługa tego wyjątku ma znaleźć się w 
kodzie który coś o Type1 i Type2 wie czyli pewnie poziom niżej. Inaczej 
kończysz na try {} catch(...) to jest jeszcze gorsze.

Wyjątki nie łapie się po każdym dodawaniu. Łapie się tam gdzie wiadomo 
co z nimi zrobić.

[toc] | [prev] | [next] | [standalone]

#32538

> Wyjątki nie łapie się po każdym dodawaniu. Łapie się tam gdzie wiadomo 
> co z nimi zrobić.

Bardzo dobrze.
Problem tylko w tym, że bardzo rzadko wiadomo, co z nimi zrobić. Często sprowadza się to do pokazania użytkownikowi komunikatu o błędzie. Albo do wrzucenia go do logu. Oba te przypadki nie mają zastosowania w systemach krytycznych takich jak sterowanie samolotem.
W szczególności, standard kodowania dla tego samolotu w ogóle zabrania używania wyjątków.

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

[toc] | [prev] | [next] | [standalone]

#32540

On 08/05/2019 07:54, Maciej Sobczak wrote:
>> Wyjątki nie łapie się po każdym dodawaniu. Łapie się tam gdzie wiadomo
>> co z nimi zrobić.
> Bardzo dobrze.

To jakiś egzamin?

> Problem tylko w tym, że bardzo rzadko wiadomo, co z nimi zrobić.

I jaki to ma związek z narzekaniem na jezyk C++?

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

> Oba te przypadki nie mają zastosowania w systemach krytycznych takich jak sterowanie samolotem.

Ale przecież przykład miał służyć marudzeniu o bezdennnym dziadostwie C++.

> W szczególności, standard kodowania dla tego samolotu w ogóle zabrania używania wyjątków.

Standardy kodowania zawiarają dużo więceń wykluczeń, wiele z nich 
generuje po stronie programisty emulacje zachowań wykluczonych.

Taki mały przykłąd z systemu krytycznego:

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.

[toc] | [prev] | [next] | [standalone]

#32543

> > Bardzo dobrze.
> 
> To jakiś egzamin?

A jakbym normalnie i zgodnie z grupowymi zwyczajami zawalił Cię bluzgami, to by nie był? :-)

> > Problem tylko w tym, że bardzo rzadko wiadomo, co z nimi zrobić.
> 
> I jaki to ma związek z narzekaniem na jezyk C++?

Myślałem, że narzekamy na standard kodowania. 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.

> Ale przecież przykład miał służyć marudzeniu o bezdennnym dziadostwie C++.

Właśnie zgubiłem się, co hejtujemy. Jeśli C++, to niesłusznie (co za niespodzianka!), bo zakaz wyjątków jest niezależny od języka.

> Taki mały przykłąd z systemu krytycznego:
> 
> 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. Jeżeli są wyjątki, to tych ścieżek nawet nie widać 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. 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.
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.

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

[toc] | [prev] | [next] | [standalone]

#32546

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.

[toc] | [prev] | [next] | [standalone]

#32549

> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | pl.comp.programming

csiph-web