🚀 go-pugleaf

On 2019-09-03 10:58, Maciej Sobczak wrote:
>> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
> 
> Uniwersytety robią to w tempie 3 języki na rok. Nic z tego. To tak nie działa.

Ada nie powstala na uniwersystecie. PL/I tez nie.

AK

On 2019-09-03 10:58, Maciej Sobczak wrote:
>> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
>> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
>> o wymioty... :(
> 
> Przemysł ma inne zdanie. Nie da się zakazać używania języka C.

Po prwwsze: Przemysl nieraz dowiodl (i ciagle dowodzi), ze za madry
nie jest... ("wiedza" managementu brana z prezentacji i video-konferencji).
Po drugie: Otoz da sie. Bardzo prosto.
Poza tym (jak pisalem) nie jest to niezbedne.
Wystarczy stworzyc kompilator z zaszytymi restrykcjami Misry.
Jezyk niech sie zwie po prostu Misra-C

> I nawet chyba nie należy. Lepiej dać ludziom wytyczne, jakie cele jakościowe mają osiągnąć i niech sobie sami wybiorą, czym je będą osiągać. To jest pole dla konkurencji - tzn. jeśli potrafisz te cele osiągnąć taniej, niż konkurencja używająca języka C, to Twój zysk.
> Tylko jakoś nikt się nie wychyla i dalej wszyscy "konkurują" robiąc wszystko tak samo, jak reszta.

Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
tym samym mlotkiem w leb potraktowac.

AK

On Tuesday, September 3, 2019 at 6:43:54 PM UTC+2, AK wrote:
> On 2019-09-03 10:58, Maciej Sobczak wrote:
> >> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
> >> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
> >> o wymioty... :(
> > 
> > Przemysł ma inne zdanie. Nie da się zakazać używania języka C.
> 
> Po prwwsze: Przemysl nieraz dowiodl (i ciagle dowodzi), ze za madry
> nie jest... ("wiedza" managementu brana z prezentacji i video-konferencji).
> Po drugie: Otoz da sie. Bardzo prosto.
> Poza tym (jak pisalem) nie jest to niezbedne.
> Wystarczy stworzyc kompilator z zaszytymi restrykcjami Misry.
> Jezyk niech sie zwie po prostu Misra-C
> 
> > I nawet chyba nie należy. Lepiej dać ludziom wytyczne, jakie cele jakościowe mają osiągnąć i niech sobie sami wybiorą, czym je będą osiągać. To jest pole dla konkurencji - tzn. jeśli potrafisz te cele osiągnąć taniej, niż konkurencja używająca języka C, to Twój zysk.
> > Tylko jakoś nikt się nie wychyla i dalej wszyscy "konkurują" robiąc wszystko tak samo, jak reszta.
> 
> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
> tym samym mlotkiem w leb potraktowac.

Dlaczego porównanie języka programowania do gumowego młotka jest 
dobre?

Pozdrawiam

On 2019-09-03 20:04, M.M. wrote:
>> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
>> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
>> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
>> tym samym mlotkiem w leb potraktowac.
> 
> Dlaczego porównanie języka programowania do gumowego młotka jest
> dobre?

Dlatego ze dosłowną wrecz implementacją "paradygmatu" gumowego mlotka
w dziedzinie okraszonej slowem "safety" jest wrecz stworzony do
problemow j.prog. C/C++.

AK

> >> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
> > 
> > Uniwersytety robią to w tempie 3 języki na rok. Nic z tego. To tak nie działa.
> 
> Ada nie powstala na uniwersystecie. PL/I tez nie.

Chciałeś, żeby był nowy.

-- 
Maciej Sobczak

> > Przemysł ma inne zdanie. Nie da się zakazać używania języka C.
> 
> Po prwwsze: Przemysl nieraz dowiodl (i ciagle dowodzi), ze za madry
> nie jest...

Ale ma moc podejmowania decyzji. Mądrych bądź nie.

> Po drugie: Otoz da sie. Bardzo prosto.

Szkoda, że zapomniałeś napisać, jak.
Zauważmy tutaj, że w systemach (mniej lub bardziej) demokratycznych to właśnie przemysł ostatecznie powołuje i finansuje te wszystkie komitety. Taki jest kierunek przepływu kasy.
Jako ćwiczenie wyobraź sobie, że jakiś minister zabroniłby palić węglem (bo smog, itd.). W efekcie to nie węgiel by zniknął z rynku, tylko ten minister. Tak to działa.

Dlatego węgiel oraz język C zostaną.

> Wystarczy stworzyc kompilator z zaszytymi restrykcjami Misry.
> Jezyk niech sie zwie po prostu Misra-C

Czyli potwierdziłeś właśnie, że rozwiązaniem jest zachować język C. No i tak się dzieje.
A kompilator z restrykcjami, oczywiście - bierzemy jakibądź kompilator i dodajemy do niego jakibądź tool do sprawdzania reguł. I mamy kompletne narzędzie. Tak się właśnie dzieje. Nie trzeba robić nowych narzędzi, wszystko już jest gotowe, nawet jest w czym wybierać.

> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
> tym samym mlotkiem w leb potraktowac.

Ale tak się nie robi. Pisze się wymagania, że gwóźdź ma być wbity i tyle. A firmy konkurują wbijając gwoździe gumowymi młotkami, bo tylko tak umieją a ci co wiedzą lepiej akurat nie prowadzą żadnej własnej firmy, żeby w tej rynkowej konkurencji w ogóle mieć coś do powiedzenia i mogą sobie co najwyżej bezproduktywnie popyskować na grupach dyskusyjnych. I skoro ostatecznie gwóźdź jest wbity zgodnie z wymaganiami a klient i tak płaci, to w czym problem?

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

On Tuesday, September 3, 2019 at 8:26:10 PM UTC+2, AK wrote:
> On 2019-09-03 20:04, M.M. wrote:
> >> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
> >> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
> >> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
> >> tym samym mlotkiem w leb potraktowac.
> > 
> > Dlaczego porównanie języka programowania do gumowego młotka jest
> > dobre?
> 
> Dlatego ze dosłowną wrecz implementacją "paradygmatu" gumowego mlotka
> w dziedzinie okraszonej slowem "safety" jest wrecz stworzony do
> problemow j.prog. C/C++.

Zrozumiałem jak używasz porównanie jednej nieefektywnej pracy do drugiej.
Nie rozumiem zaś co ma wspólnego gumowy młotek z językami programowania.
Tak samo ja bym mógł powiedzieć, że proponowane przez Ciebie metody
tworzenia krytycznych programów są jak cokolwiek nieefektywnego, np.
jak kopanie studni głębinowej szczoteczką do zębów, i też byś nie 
wiedział co ma wspólnego szczoteczka do zębów i studnia głębinowa z
proponowanymi przez Ciebie metodami.

Pozdrawiam.

>NASA jako pop-kulturowego brandu, to nie NASA jest frontem walki o jakość - wynika to z faktu, że w tej branży (podobnie jak w wojsku) nie obowiązują reguły certyfikacji czy homologacji takie jak w cywilnych branżach.

NASA jest cywilna, choć rządowa. Natomiast wojsko zawsze i
 wszędzie kocha standardy i regulaminy: kaliber broni, długość
 onuc, ... Sławetne normy MIL.


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

Maciej Sobczak <see.my.homepage@gmail.com> Wrote in message:
> Mnie na tej liście uderzyła reguła, że w kodzie ma być ileś tam assertów.

Dziwne także dlatego że assert zgłasza coś tylko wtedy gdy akurat
 jakoś się zdarzy. 

Lepiej robić testy jednostkowe - czyli nie czekać aż się zdarzy -
 lecz aktywnie testować solidność próbując agresywnie
 zepsuć.

Do tego assert pięknie można wyłączyć. A jakby co to in the deep
 space te asserty będą nawet nie psu na budę. Kompletnie bez
 znaczenia.


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

On 2019-09-03 20:51, Maciej Sobczak wrote:
>>>> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
>>>
>>> Uniwersytety robią to w tempie 3 języki na rok. Nic z tego. To tak nie działa.
>>
>> Ada nie powstala na uniwersystecie. PL/I tez nie.
> 
> Chciałeś, żeby był nowy.

Taaak? Tez się starzejesz ;)
<cycat>Dlatego, że zamiast dopracować "nowy" język programowania</cycat>

AK

On 2019-09-04 08:32, M.M. wrote:
> On Tuesday, September 3, 2019 at 8:26:10 PM UTC+2, AK wrote:
>> On 2019-09-03 20:04, M.M. wrote:
>>>> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
>>>> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
>>>> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
>>>> tym samym mlotkiem w leb potraktowac.
>>>
>>> Dlaczego porównanie języka programowania do gumowego młotka jest
>>> dobre?
>>
>> Dlatego ze dosłowną wrecz implementacją "paradygmatu" gumowego mlotka
>> w dziedzinie okraszonej slowem "safety" jest wrecz stworzony do
>> problemow j.prog. C/C++.
> 
> Zrozumiałem jak używasz porównanie jednej nieefektywnej pracy do drugiej.
> Nie rozumiem zaś co ma wspólnego gumowy młotek z językami programowania.

Bo C/C++ _jest_ typowym gumowym mlotkiem w dziedzinie 'safety' (wbijanie
gwozdzi).

> Tak samo ja bym mógł powiedzieć, że proponowane przez Ciebie metody
> tworzenia krytycznych programów są jak cokolwiek nieefektywnego, np.
> jak kopanie studni głębinowej szczoteczką do zębów, i też byś nie
> wiedział co ma wspólnego szczoteczka do zębów i studnia głębinowa z
> proponowanymi przez Ciebie metodami.

Stosowanie C/C++ w 'safety' to... kopanie studni... odbezpieczonym
granatem. Wiadomo, ze wybuchnie (reka sie zmeczy) tylko nie wiadomo
kiedy i co urwie (d..pę czy głowę...).

PS: Nic nie mam do gumowych mlotkow. Swietnie nadaja sie np. do robot
dekarskich czy samochodowej blacharki. No ale _nie do wbijania gwozdzi_.

AK

On 2019-09-03 21:33, godek.maciek@gmail.com wrote:
> Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne przekonanie,
>  że asercja to "sprawdzenie czegoś w runtimie".

Alez oczywiscie, ze w C/C++ zwykla asercja jest "sprawdzana" w runtime!.
To nie zadne bledne przekonanie. To niezaprzeczalny fakt!.

PS: Tak to jest jak jakis niedouczony w C/C++ Lispowiec bez
     zastanowienia/sprawdzenia strzepi jezor na temat o ktorym nie ma
     zielonego pojecia (C/C++)

AK

On 2019-09-04 09:53, godek.maciek@gmail.com wrote:
> Asercja to postawa propozycjonalna.
> Możesz sobie napisać
> #define assert(x) do {} while(0)
> i nie masz śladu w kodzie maszynowym.

Chlopcze. Prosze, doucz sie o assercjach w C/C++.
Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(
Zapewniam Cie, ze w k.maszynowym nie bedzie sladu po kodzie asercji.

AK

On 2019-09-04 19:04, AK wrote:
> Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(

autopoprawka:
z NDEBUG lub bez DEBUG-a :(

AK

W dniu środa, 4 września 2019 19:04:38 UTC+2 użytkownik AK napisał:

> > Asercja to postawa propozycjonalna.
> > Możesz sobie napisać
> > #define assert(x) do {} while(0)
> > i nie masz śladu w kodzie maszynowym.
> 
> Chlopcze. Prosze, doucz sie o assercjach w C/C++.

"Assercjach"? "Chłopcze"?

> Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(

Można z -DNDEBUG, jak się bierze asercje z "assert.h".
Ja zazwyczaj nie biorę, bo chce mieć lepszą kontrolę nad tym, co się dzieje, gdy dokona się asercji fałszu.

To jednak nie zmienia istoty tego, czym jest asercja.

On 2019-09-04 19:54, godek.maciek@gmail.com wrote:
> W dniu środa, 4 września 2019 19:04:38 UTC+2 użytkownik AK napisał:
> 
>>> Asercja to postawa propozycjonalna.
>>> Możesz sobie napisać
>>> #define assert(x) do {} while(0)
>>> i nie masz śladu w kodzie maszynowym.
>>
>> Chlopcze. Prosze, doucz sie o assercjach w C/C++.
> 
> "Assercjach"? "Chłopcze"?

Typowe szczeniackie czepianie sie pierdół.

>> Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(
> 
> Można z -DNDEBUG, jak się bierze asercje z "assert.h".
> Ja zazwyczaj nie biorę,

To nie pierdziel juz wiecej o assercjach w C.
Asercje w C bierze sie _tylko i wylacznie_ z assert.h
Twoje prywatne "robotki domowe"to nie asercje w C.

> To jednak nie zmienia istoty tego, czym jest asercja.

Pieprzysz 3po3.

AK

W dniu środa, 4 września 2019 21:07:20 UTC+2 użytkownik AK napisał:

> >> Chlopcze. Prosze, doucz sie o assercjach w C/C++.
> > 
> > "Assercjach"? "Chłopcze"?
> 
> Typowe szczeniackie czepianie sie pierdół.

Ale mówisz teraz o swojej uwadze odnośnie NDEBUG czy o czym, bo już się zgubiłem?

> >> Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(
> > 
> > Można z -DNDEBUG, jak się bierze asercje z "assert.h".
> > Ja zazwyczaj nie biorę,
> 
> To nie pierdziel juz wiecej o assercjach w C.
> Asercje w C bierze sie _tylko i wylacznie_ z assert.h
> Twoje prywatne "robotki domowe"to nie asercje w C.

A co sprawia, że te z assert.h to "prawdziwe asercje", a te "moje prywatne robótki domowe" -  "nieprawdziwe"?

Jakieś namaszczenie wysokiego kapłana?

> > To jednak nie zmienia istoty tego, czym jest asercja.
> 
> Pieprzysz 3po3.

?

On Wednesday, September 4, 2019 at 6:52:22 PM UTC+2, AK wrote:
> On 2019-09-04 08:32, M.M. wrote:
> > On Tuesday, September 3, 2019 at 8:26:10 PM UTC+2, AK wrote:
> >> On 2019-09-03 20:04, M.M. wrote:
> >>>> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
> >>>> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
> >>>> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
> >>>> tym samym mlotkiem w leb potraktowac.
> >>>
> >>> Dlaczego porównanie języka programowania do gumowego młotka jest
> >>> dobre?
> >>
> >> Dlatego ze dosłowną wrecz implementacją "paradygmatu" gumowego mlotka
> >> w dziedzinie okraszonej slowem "safety" jest wrecz stworzony do
> >> problemow j.prog. C/C++.
> > 
> > Zrozumiałem jak używasz porównanie jednej nieefektywnej pracy do drugiej.
> > Nie rozumiem zaś co ma wspólnego gumowy młotek z językami programowania.
> 
> Bo C/C++ _jest_ typowym gumowym mlotkiem w dziedzinie 'safety' (wbijanie
> gwozdzi).

Ok, ale napisz coś na temat tego czego nie rozumiem, zamiast pisać trzeci
raz to co dobrze zrozumiałem.

> 
> > Tak samo ja bym mógł powiedzieć, że proponowane przez Ciebie metody
> > tworzenia krytycznych programów są jak cokolwiek nieefektywnego, np.
> > jak kopanie studni głębinowej szczoteczką do zębów, i też byś nie
> > wiedział co ma wspólnego szczoteczka do zębów i studnia głębinowa z
> > proponowanymi przez Ciebie metodami.
> 
> Stosowanie C/C++ w 'safety' to... kopanie studni... odbezpieczonym
> granatem. Wiadomo, ze wybuchnie (reka sie zmeczy) tylko nie wiadomo
> kiedy i co urwie (d..pę czy głowę...).

Rozumiem co chcesz powiedzieć, nie mam tylko bladego pojęcia jak to
uzasadniasz. Dlaczego wedlug Ciebie C++ nie nadaje się do programowania
krytycznych aplikacji. Mowa oczywiście o dobrym C++ w rękach dobrego 
programisty.

 
> PS: Nic nie mam do gumowych mlotkow. Swietnie nadaja sie np. do robot
> dekarskich czy samochodowej blacharki. No ale _nie do wbijania gwozdzi_.

W C/C++ jest napisana duża część systemów operacyjnych i sterowników, a
dużo systemów krytycznych pracuje na systemach operacyjnych. Dużo 
bibliotek jest napisanych w C/C++, z których nawet inne języki korzystają.
Jeśli C/C++ się nie nadaje do bezpiecznego programowania, to większość
systemów nie jest bezpieczna, bo jest mocno(!) zależna od tego co jest
napisane w C/C++.


Pozdrawiam

On Wednesday, September 4, 2019 at 11:05:02 PM UTC+2, godek...@gmail.com wrote:
> A co sprawia, że te z assert.h to "prawdziwe asercje", a te "moje prywatne 
> robótki domowe" -  "nieprawdziwe"?

Dla bezpieczeństwa, bo w końcu o bezpieczeństwie rozmawiamy, możesz 
wyjść z laptopem do parku i tam napisać asserta - wtedy nikt Ci nie 
zarzuci że to domowe samoróbki ;-)

Pozdrawiam

On 2019-09-04 23:05, godek.maciek@gmail.com wrote:
> W dniu środa, 4 września 2019 21:07:20 UTC+2 użytkownik AK napisał:
> 
>>>> Chlopcze. Prosze, doucz sie o assercjach w C/C++.
>>>
>>> "Assercjach"? "Chłopcze"?
>>
>> Typowe szczeniackie czepianie sie pierdół.
> 
>  bo już się zgubiłem?

To się odgub.

>>>> Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(
>>>
>>> Można z -DNDEBUG, jak się bierze asercje z "assert.h".
>>> Ja zazwyczaj nie biorę,
>>
>> To nie pierdziel juz wiecej o assercjach w C.
>> Asercje w C bierze sie _tylko i wylacznie_ z assert.h
>> Twoje prywatne "robotki domowe"to nie asercje w C.
> 
> A co sprawia, że te z assert.h to "prawdziwe asercje", a te "moje prywatne robótki domowe" -  "nieprawdziwe"?
> 
> Jakieś namaszczenie wysokiego kapłana?

Tak. Ten kapłan zwie się Standard Języka C.

>>> To jednak nie zmienia istoty tego, czym jest asercja.
>>
>> Pieprzysz 3po3.
> 
> ?

Pier..lisz głupoty.

AK

On Friday, September 6, 2019 at 7:31:09 AM UTC+2, AK wrote:
> On 2019-09-04 23:05, g@g.c wrote:
> > W dniu środa, 4 września 2019 21:07:20 UTC+2 użytkownik AK napisał:
> > 
> >>>> Chlopcze. Prosze, doucz sie o assercjach w C/C++.
> >>>
> >>> "Assercjach"? "Chłopcze"?
> >>
> >> Typowe szczeniackie czepianie sie pierdół.
> > 
> >  bo już się zgubiłem?
> 
> To się odgub.
> 
> >>>> Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(
> >>>
> >>> Można z -DNDEBUG, jak się bierze asercje z "assert.h".
> >>> Ja zazwyczaj nie biorę,
> >>
> >> To nie pierdziel juz wiecej o assercjach w C.
> >> Asercje w C bierze sie _tylko i wylacznie_ z assert.h
> >> Twoje prywatne "robotki domowe"to nie asercje w C.
> > 
> > A co sprawia, że te z assert.h to "prawdziwe asercje", a te "moje prywatne robótki domowe" -  "nieprawdziwe"?
> > 
> > Jakieś namaszczenie wysokiego kapłana?
> 
> Tak. Ten kapłan zwie się Standard Języka C.
> 
> >>> To jednak nie zmienia istoty tego, czym jest asercja.
> >>
> >> Pieprzysz 3po3.
> > 
> > ?
> 
> Pier..lisz głupoty.
> 
> AK

A uzasadnienia i tak i tak nie będzie.

Pora na kawał. Rozmawia dwóch informatyków. Jeden pyta:
 - dlaczego tak myślisz kolego?
Drugi odpowiada:
 - co cie to obchodzi!

On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
> A uzasadnienia i tak i tak nie będzie.

AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie 
widziałem by kiedykolwiek sam cokolwiek mądrego napisał. Niemniej (a 
raczej tym bardziej) jestem pod wrażeniem cierpliwości którą kolega 
wykazuje.

> Pora na kawał. Rozmawia dwóch informatyków. Jeden pyta:
>  - dlaczego tak myślisz kolego?
> Drugi odpowiada:
>  - co cie to obchodzi!

Tutaj bardziej adekwatny byłby taki wariant:
- dlaczego tak myślisz kolego?
- BO TY GUPI JESTEŚ, WIEM LEPIEJ!!!
- ależ kolego, proszę wyjaśnić
- SPIERDALAJ!!!

Ale nie żeby to był ewenement jakiś - to niestety częsty przypadek w 
ogólno-pojętym IT. :)

Mateusz

On Friday, September 6, 2019 at 10:33:01 AM UTC+2, Mateusz Viste wrote:
> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
> > A uzasadnienia i tak i tak nie będzie.
> 
> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie 
> widziałem by kiedykolwiek sam cokolwiek mądrego napisał. Niemniej (a 
> raczej tym bardziej) jestem pod wrażeniem cierpliwości którą kolega 
> wykazuje.

Rozmowa, a przynajmniej któryś post, wydała się bardzo ciekawa i, nawet
nie byłem cierpliwy, tylko zwyczajnie chciałem się dowiedzieć jaka
jest (najlepiej kompletna) lista argumentów za tym, że C++ nie nadaje 
się do tworzenia niezawodnych systemów. I, rzecz jasna, jaka jest 
alternatywa dla C++, bo jak C++ ma wady, a nie ma nic wyraźnie lepszego,
to żadne argumenty mnie nie przekonają. 

Warto zobaczyć ile błędów było w różnych kompilatorach w różnych językach. 
Do C/C++ jest dużo niezależnych kompilatorów, można więc łatwo zrobić 
testy krzyżowe - to już jest mocny argument za użyciem C++. Ja często 
bym wolał coś w okolicach języka D, ale D nie ma takiego wsparcia jak C++,
więc używam C++.

Potem koszty, ciekawe ile kosztuje dobry programista w niszowym-dedykowanym
języku? Może dwóch programistów w C++ napisze bezpieczniejszy kod, niż
jeden (za te same pieniądze) w niszowym-dedykowanym języku?

Potem mnogość bibliotek. Do C++ jest całkiem sporo, często biblioteki są
pisane natywnie w C/C++, a dopiero później robi się port do innych języków.
Robienie portu to dodatkowa okazja do popełnienia błędów, więc bezpieczniej 
jest w natywnej. A jeśli do dedykowanego języka nie ma bibliotek, to ciekawe
ile błędów narobią, albo ile czasu stracą na tworzenie/portowanie swojej biblioteki? Może w tym czasie poprawili by właściwy kod aplikacji w C++?

Kolejna sprawa, napisałem w C/C++ sporo, w tym też kilka pewnych aplikacji.
Defakto były to malutkie aplikacje, ale wcale nie były trywialne obliczeniowo. 
Z powodu agresywnej optymalizacji są zaprzeczeniem bezpiecznego stylu 
programowania. Mimo to, działają do dziś, od wielu lat nie miałem zgłoszenia
błędu. Jeśli aplikacja nie musi być super zoptymalizowana (mowa o optymalizacji
na jeden procesor, bo w zamian za to, aplikację nadal można optymalizować na
klastry i/albo GPU) to można w C++ stworzyć aplikację składającą się np. w 98% z
czytelnego i bezpiecznego kodu. Pozostałe 2% nie jest kulą u nogi, lecz pomaga
utrzymać jeszcze większy porządek w tych 98%, stanowi dobrze wydzielone 
procedury wielokrotnie użyte (a więc dobrze przetestowane) w kodzie.


Co tu by jeszcze dorzucić na korzyść C/C++... Może to, że jeśli aplikację
jednak trzeba trochę zopytmalizować na jeden procesor, to do C/C++ są
bardzo dobre optymalizatory. Więc w takich przypadkach w C++ można sobie 
napisać czytelnie, a martwi się optymalizator. W innych językach które
nie mają takiego wsparcia może trzeba jakieś haki czasami w kodzie robić, 
żeby procesor/ram nadążył.

Oczywiście C++ ma wady, ale te wady wynikają ani z języka, ani z narzędzi,
ani z bibliotek, lecz z ogromnej swobody programowania jaką daje język
C++. Jeśli, szczególnie mniej doświadczony, programista dostanie wiele 
swobody, to niewykluczone że użyje jej przeciwko bezpieczeństwu systemu.
W C++ np. nie ma obowiązku inicjowania zmiennych przy deklaracji, a domyślnie 
są inicjowane tylko w określonych sytuacjach. Jeśli ktoś w krytycznych 
systemach zbagatelizuje ten problem, uzna np. że jego kod jest na tyle
dobry, że nie będzie odczytów przed inicjacją, to cóż... można przenieść
rozmowę na grunt czy to wina programisty, czy języka, narzędzi i bibliotek.
Moim zdaniem to wina programisty, a kompilatory w C++ dają sporo ostrzeżeń
przy ryzykownych konstrukcjach.

Nie chce mi się dalej ciągnąć, bo autor nie powiedział co jest takiego
złego w C++.

Pozdrawiam

On Fri, 06 Sep 2019 03:06:02 -0700, M.M. wrote:
> Oczywiście C++ ma wady, ale te wady wynikają ani z języka, ani z
> narzędzi, ani z bibliotek, lecz z ogromnej swobody programowania jaką
> daje język C++. Jeśli, szczególnie mniej doświadczony, programista
> dostanie wiele swobody, to niewykluczone że użyje jej przeciwko
> bezpieczeństwu systemu.

W zupełności się zgadzam, dodam od siebie tylko to: język C++ rośnie cały 
czas. To bogactwo językowe, postrzegane przez wielu jako zaleta, 
faktycznie pozwala w wielu przypadkach nieco ułatwić pracę. Problem w 
tym, że w praktyce mało który programista panuje nad całością języka - 
pewnych rzeczy nie wie, albo myśli że wie i kod działa mu z przypadku, 
albo kiedyś wiedział ale zapomniał bo mało używał. No i oczywiście zbiór 
wiadomości które programista A posiada, mało kiedy nakłada się na to, co 
wie programista B. W jakiejkolwiek pracy zespołowej to może szybko być 
poważnym problemem, bo zamiast rozwiązywać biznesowe problemy, 
programiści głowią się nad tym, "co kolega miał na myśli".

To jest główny powód, dla którego ja sam staram ograniczać się do C89. 
Czasem zdarzy mi się sięgnąć po C99 albo jakieś rozszerzenie GNU, ale 
bardzo niechętnie i wyłącznie w przypadkach kiedy w oczywisty sposób 
pozwoli to ograniczyć koszty.

Oczywiście można spierać się, czy taki ogranicznik jest rolą języka, czy 
może reguł projektowych, czy też innych wewnętrznych dyrektyw.

> W C++ np. nie ma obowiązku inicjowania zmiennych przy deklaracji, a
> domyślnie są inicjowane tylko w określonych sytuacjach. Jeśli ktoś w
> krytycznych systemach zbagatelizuje ten problem, uzna np. że jego kod
> jest na tyle dobry, że nie będzie odczytów przed inicjacją, to cóż...

Akurat ten przykład jest może nie do końca trafiony, bo błąd o którym 
piszesz zostanie wykryty przez każdą statyczną analizę (nie potrzeba 
nawet do tego specjalnego analizatora - zarówno gcc jak i clang 
ostrzegają o tym). No chyba, że ktoś kompiluje bez żadnej diagnostyki... 
No ale to już mówimy o ostro patologicznych przypadkach.

Wracając do tematu bezpieczeństwa C/C++, to z pewnością istnieją znacznie 
bezpieczniejsze języki (np. w PHP ciężko wykonać SEGFAULT...). Problem w 
tym, że ktoś piszący w C/C++ z reguły poszukuje nie tylko rozwiązania 
danego problemu, ale oczekuje także osiągów - gdyby liczyło się wyłącznie 
"bezpieczeństwo", to pisalibyśmy w jakiejś ewolucji QuickBasica :)
Jeśli wymagamy by nasz kod działał możliwie najszybciej, to trzeba godzić 
się z tym, że pracujemy niejako na otwartym sercu. Jedyne co możemy 
zrobić, to starać się hamować "kreatywność" młodych programistów i 
ograniczać kod aby był jak najłatwiejszy do zrozumienia dla każdego, a 
wynik intensywnie testować.

Mateusz
-- 
"There are only two kinds of programming languages: those people always 
bitch about and those nobody uses." -- Bjarne Stroustrup

Wątek zaczął się od NASA, więc będę się trzymał tematu i zakładam, że chodzi o naprawdę krytyczny soft a nie np. o przeglądarkę internetową, której "bezpieczeństwo" ma inny wymiar.

> I, rzecz jasna, jaka jest 
> alternatywa dla C++, bo jak C++ ma wady, a nie ma nic wyraźnie lepszego,
> to żadne argumenty mnie nie przekonają. 

Otóż C++ ma prawie same wady (jest bardzo błędogenny) i prawie wszystkie odziedziczył po C, ale *nie ma* nic wyraźnie lepszego.

Jest cała masa języków obiektywnie lepszych z punktu widzenia projektowania języków, ale albo w ogóle nie mają szans w branży krytycznej z racji polegania na nieweryfikowalnym run-time, albo nie wpływają na wysiłek weryfikacyjny, czyli na ostateczny koszt projektu. Tzn. co z tego, że Ada jest lepsza od C, skoro klepanie kodu to kilka procent wysiłku a pozostałe >90% to tyle samo roboczogodzin, bo one wynikają z procesów a nie z wyboru takiego czy innego języka.

Przykładowo, co z tego, że Ada jest lepsza, skoro nie redukuje wysiłku potrzebnego na uzyskanie 100% pokrycia testami. Testów do napisania będzie dokładnie tyle samo, co do sztuki. Dlatego użycie Ady nic nie wnosi. To są tego typu argumenty.

> Warto zobaczyć ile błędów było w różnych kompilatorach w różnych językach.

To akurat nie ma znaczenia. Kompilator może sobie mieć bugi, bo i tak weryfikuje się kod wykonywalny. Dlatego też jest mitem, że w branży krytycznej potrzebne są jakieś "certyfikowane" kompilatory. Otóż nie są (niespodzianka!).

> Potem koszty, ciekawe ile kosztuje dobry programista w niszowym-dedykowanym
> języku?

To kolejny mit. Wszyscy programiści kosztują z grubsza tyle samo, bo ich koszt i tak już dawno nie zależy od ich kompetencji. Albo wręcz dochodzi do takich lokalnych anomalii rynkowych, że np. JavaScript kosztuje więcej, niż C++.
Większym problemem jest to, że programistów niszowych języków po prostu nie ma a nie to, ile kosztują.

> Może dwóch programistów w C++ napisze bezpieczniejszy kod, niż
> jeden (za te same pieniądze) w niszowym-dedykowanym języku?

Nie. W obu przypadkach muszą napisać tak samo bezpieczny.

> Potem mnogość bibliotek.

Nie używa się bibliotek. Szkoda na to nerwów, znacznie szybciej jest napisać i zweryfikować coś od zera samemu.

(przypominam, że do tego miejsca wątek był o systemach krytycznych)

Te wszystkie rozważania wyglądają zupełnie inaczej w "normalnym" programowaniu, gdzie *najistotniejszy* jest dostęp do bogatego ekosystemu gotowych rozwiązań - biblioteki, frameworki, itd. Na tym polu, w embedded wygrywa C/C++ i w zasadzie z niczym nie konkuruje, na serwerach C++ konkuruje z Javą, na desktopie C++ konkuruje z .NETem i Javą, w przeglądarce króluje JavaScript a w zastosowaniach specjalistycznych i okołonaukowych (wliczając w to jakiś data science, AI i takie tam) na przód wybiega Python, który w jakimś stopniu jest też obecny wszędzie indziej jako scyzoryk do wszystkiego i niczego. Pozostałe języki to albo zamknięte technicznie i nieużyteczne w inny sposób ekosystemy (SQL, MATLAB, itd.) albo po prostu domena hobbystów. Szczerze - *wszystko* jest do bani. Ale podobnie jest we wszystkich innych dziedzinach życia (muzyka, film, jedzenie, itd.), więc chyba tak po prostu mamy jako cywilizacja.
I tak z grubsza to wygląda. Chyba że komuś wygląda inaczej, chętnie zobaczę.

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

On Fri, 06 Sep 2019 06:42:36 -0700, Maciej Sobczak wrote:
>> Warto zobaczyć ile błędów było w różnych kompilatorach w różnych
>> językach.
> 
> To akurat nie ma znaczenia. Kompilator może sobie mieć bugi, bo i tak
> weryfikuje się kod wykonywalny. Dlatego też jest mitem, że w branży
> krytycznej potrzebne są jakieś "certyfikowane" kompilatory. Otóż nie są
> (niespodzianka!).

Oj ale to chyba nieco naiwne - że niby przetestowanie wynikowego kodu 
zagwarantuje brak bugów. Nie zagwarantuje, bo nie ma opcji by dało się 
przetestować wynikowy program w 100% (wliczając w to np. ładowanie 
relokowalnego kodu pod najróżniejsze adresy, coby wykryć jakiś egzotyczny 
bug kompilatora). To nie znaczy oczywiście, że nie należy do tego dążyć, 
jeśli ekonomia projektu na to pozwala.

> To kolejny mit. Wszyscy programiści kosztują z grubsza tyle samo, bo ich
> koszt i tak już dawno nie zależy od ich kompetencji.

Ja tam jednak obserwuję duże różnice w zależności od języka. Im więcej 
towaru na rynku, tym bardziej jego wartość spada.

> Nie używa się bibliotek. Szkoda na to nerwów, znacznie szybciej jest
> napisać i zweryfikować coś od zera samemu.

Wliczając w to libc? Co do zasady, że lepiej samemu wyrzeźbić aby 
wpasowało się idealnie w dany projekt to się zgodzę, ale to tylko 
generalna zasada, i jak zawsze istnieje milion wyjątków. "nie używa się" 
uważam za nieco zbyt kategoryczny obraz...

> Szczerze - *wszystko* jest do bani. Ale podobnie jest we wszystkich
> innych dziedzinach życia (muzyka, film, jedzenie, itd.), więc chyba tak
> po prostu mamy jako cywilizacja.

I to faktycznie ma sens :)
"kiedyś było lepiej"

Mateusz

On 2019-09-06 10:33, Mateusz Viste wrote:
> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
>> A uzasadnienia i tak i tak nie będzie.
> 
> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
> widziałem by kiedykolwiek sam cokolwiek mądrego napisał.

Piszę same mądre (czyli prawdziwe) rzeczy :).
Nie moja wina, że głupcy ich nie dostrzegają.

AK

On 2019-09-06 10:12, M.M. wrote:
>> AK
> 
> A uzasadnienia i tak i tak nie będzie.

Gadał stary do ślepego....
<cycat>Tak. Ten kapłan zwie się Standard Języka C.<cycat/>

Tera juz ślepy widzi czy trzeba wieksza czcionka?
_To są asercje_ w C, a nie "domowe robotki na drutach" jakiegos
fanatycznego Lispiarza..

Paniał juz? Czy dla slepego to wystarczajace uzasadnienie?

AK

On Friday, September 6, 2019 at 5:12:00 PM UTC+2, AK wrote:
> On 2019-09-06 10:12, M.M. wrote:
> >> AK
> > 
> > A uzasadnienia i tak i tak nie będzie.
> 
> Gadał stary do ślepego....
> <cycat>Tak. Ten kapłan zwie się Standard Języka C.<cycat/>
> 
> Tera juz ślepy widzi czy trzeba wieksza czcionka?
> _To są asercje_ w C, a nie "domowe robotki na drutach" jakiegos
> fanatycznego Lispiarza..
> 
> Paniał juz? Czy dla slepego to wystarczajace uzasadnienie?
> 

Nie, nie zrozumiałem. Rozwiń jeśli możesz.
Pozdrawiam

W dniu piątek, 6 września 2019 07:31:09 UTC+2 użytkownik AK napisał:

> 
> >>>> Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(
> >>>
> >>> Można z -DNDEBUG, jak się bierze asercje z "assert.h".
> >>> Ja zazwyczaj nie biorę,
> >>
> >> To nie pierdziel juz wiecej o assercjach w C.
> >> Asercje w C bierze sie _tylko i wylacznie_ z assert.h
> >> Twoje prywatne "robotki domowe"to nie asercje w C.
> > 
> > A co sprawia, że te z assert.h to "prawdziwe asercje", a te "moje prywatne robótki domowe" -  "nieprawdziwe"?
> > 
> > Jakieś namaszczenie wysokiego kapłana?
> 
> Tak. Ten kapłan zwie się Standard Języka C.

A jeżeli ktoś zdefiniuje sobie, dajmy na to, w C89, makro do statycznych asercji, takie np. jak sugeruje ten gość:
https://stackoverflow.com/a/3385694
czyli dla tych, którym nie chce się klikać
#define STATIC_ASSERT(COND,MSG) typedef char static_assertion_##MSG[(COND)?1:-1]

i będzie używał tego makra do wyrażania różnych zależności, które zakłada, że muszą być spełnione w swoim programie, np.

STATIC_ASSERT(sizeof(mytype) <= sizeof(int), mytype_fits_machine_word)

to czy to są prawdziwe asercje, czy nieprawdziwe?

Czy Standard Języka C powinien nałożyć ekskomunikę na tego gościa?

> >>> To jednak nie zmienia istoty tego, czym jest asercja.
> >>
> >> Pieprzysz 3po3.
> > 
> > ?
> 
> Pier..lisz głupoty.

To Twoje prawdziwe imię i nazwisko, czy tylko ksywka?

Ale dobrze, jeśli sobie życzysz, mogę tak do Ciebie mówić, Pierdoliszu.

Nawet ładnie to brzmi.

Ciekaw tylko jestem, jak się odmienia nazwisko.

"Wdałem się w dyskusję z Pierdoliszem Głupotym"? Hmm

On Friday, September 6, 2019 at 7:14:31 PM UTC+2, g@g.c wrote:
> W dniu piątek, 6 września 2019 07:31:09 UTC+2 użytkownik AK napisał:
> 
> > 
> > >>>> Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(
> > >>>
> > >>> Można z -DNDEBUG, jak się bierze asercje z "assert.h".
> > >>> Ja zazwyczaj nie biorę,
> > >>
> > >> To nie pierdziel juz wiecej o assercjach w C.
> > >> Asercje w C bierze sie _tylko i wylacznie_ z assert.h
> > >> Twoje prywatne "robotki domowe"to nie asercje w C.
> > > 
> > > A co sprawia, że te z assert.h to "prawdziwe asercje", a te "moje prywatne robótki domowe" -  "nieprawdziwe"?
> > > 
> > > Jakieś namaszczenie wysokiego kapłana?
> > 
> > Tak. Ten kapłan zwie się Standard Języka C.
> 
> A jeżeli ktoś zdefiniuje sobie, dajmy na to, w C89, makro do statycznych asercji, takie np. jak sugeruje ten gość:
> https://stackoverflow.com/a/3385694
> czyli dla tych, którym nie chce się klikać
> #define STATIC_ASSERT(COND,MSG) typedef char static_assertion_##MSG[(COND)?1:-1]
> 
> i będzie używał tego makra do wyrażania różnych zależności, które zakłada, że muszą być spełnione w swoim programie, np.
> 
> STATIC_ASSERT(sizeof(mytype) <= sizeof(int), mytype_fits_machine_word)
> 
> to czy to są prawdziwe asercje, czy nieprawdziwe?
> 
> Czy Standard Języka C powinien nałożyć ekskomunikę na tego gościa?

Są to prawdziwe asercje, ładne, standard nie powinien nałożyć ekskomuniki, bo
są zgodne ze standardem, można dorzucić dwa oczywiste fakty:
1) Pisanie czegoś samemu jest bardziej ryzykowne niż używanie 
   dobrze przetestowanych bibliotek.
2) Taki prosty asert (bez pisania czegoś samemu) z biblioteki ma za mało
   funkcjonalności do której się przyzwyczaiłem.

Więc niech każdy, zgodnie z ideą elastyczności C++, wybierze co dla niego
lepsze. Albo używaj skąpych gotowców, albo zaryzykuj napisanie bardziej
rozbudowanych asercji.

Pozdrawiam

> Oj ale to chyba nieco naiwne - że niby przetestowanie wynikowego kodu 
> zagwarantuje brak bugów.

Nie zagwarantuje, tylko potwierdzi. Bo niby jak inaczej?

> Nie zagwarantuje, bo nie ma opcji by dało się 
> przetestować wynikowy program w 100%

Witamy w branży systemów krytycznych. To nie jest opcja, tylko poziom oczekiwany.
I dlaczego miałoby się nie dać?

> (wliczając w to np. ładowanie 
> relokowalnego kodu

Nie ma relokowalnego kodu. Właśnie dlatego.

> To nie znaczy oczywiście, że nie należy do tego dążyć, 
> jeśli ekonomia projektu na to pozwala.

Ekonomia jest taka, że ma być 100%.

> > To kolejny mit. Wszyscy programiści kosztują z grubsza tyle samo, bo ich
> > koszt i tak już dawno nie zależy od ich kompetencji.
> 
> Ja tam jednak obserwuję duże różnice w zależności od języka. Im więcej 
> towaru na rynku, tym bardziej jego wartość spada.

Ale to nie zależy od niszowości języka, tylko od podaży i popytu. Jeżeli język X jest niszowy, to i tak jedyny programista w Polsce będzie tanim hobbystą, jeśli będzie dla niego 0 projektów. Niszowość mu nie pomoże.
Problemem na rynku pracy jest brak programistów w ogóle a nie to, czy coś jest niszowe, czy nie.

> > Nie używa się bibliotek. Szkoda na to nerwów, znacznie szybciej jest
> > napisać i zweryfikować coś od zera samemu.
> 
> Wliczając w to libc?

Tak. W sumie i tak nie ma tam nic ciekawego z punktu widzenia jakiegokolwiek systemu krytycznego.

> "nie używa się" 
> uważam za nieco zbyt kategoryczny obraz...

Nie używa się, bo obcy (!) kod jest bardziej kosztowny w weryfikacji, niż własny. Obowiązek zapewnienia 100% pokrycia istnieje dla *całego* kodu a nie tylko dla jakiegoś drobnego kawałka, który napisałeś sam, a pokrywanie kodu jakiejś obcej biblioteki albo wykazywanie jej zgodności z wymaganiami projektu to jest coś, czego nikt nie chciałby robić.

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

On Fri, 06 Sep 2019 12:03:02 -0700, Maciej Sobczak wrote:
> Obowiązek zapewnienia 100% pokrycia istnieje dla *całego*
> kodu a nie tylko dla jakiegoś drobnego kawałka, który napisałeś sam, a
> pokrywanie kodu jakiejś obcej biblioteki albo wykazywanie jej zgodności
> z wymaganiami projektu to jest coś, czego nikt nie chciałby robić.

W tym momencie zdałem sobie sprawę, że myślimy o całkiem innych rzeczach 
- tzn. ty piszesz o tworze dużo bardziej ekstremalnym niż założyłem (co 
jest zupełnie zgodne z pierwotnym tematem "NASA").

No i faktycznie - jeśli przyjąć, że piszemy logikę kontrolera stacji 
orbitalnej Jowisza, to "normalne" programowanie odpada. Zostaje pisanie 
pod "bare metal", gdzie program musi być wrzucony pod ściśle określony 
adres, każda zmienna ma ściśle określone miejsce w pamięci, a sam program 
jest sprawdzony za pomocą wszystkich możliwych kombinacji danych.

Mateusz

W dniu piątek, 6 września 2019 20:28:58 UTC+2 użytkownik M.M. napisał:

> > A jeżeli ktoś zdefiniuje sobie, dajmy na to, w C89, makro do statycznych asercji, takie np. jak sugeruje ten gość:
> > https://stackoverflow.com/a/3385694
> > czyli dla tych, którym nie chce się klikać
> > #define STATIC_ASSERT(COND,MSG) typedef char static_assertion_##MSG[(COND)?1:-1]
> > 
> > i będzie używał tego makra do wyrażania różnych zależności, które zakłada, że muszą być spełnione w swoim programie, np.
> > 
> > STATIC_ASSERT(sizeof(mytype) <= sizeof(int), mytype_fits_machine_word)
> > 
> > to czy to są prawdziwe asercje, czy nieprawdziwe?
> > 
> > Czy Standard Języka C powinien nałożyć ekskomunikę na tego gościa?
> 
> Są to prawdziwe asercje, ładne, standard nie powinien nałożyć ekskomuniki, bo
> są zgodne ze standardem,

Moje prywatne "domowe robótki" też są zgodne ze standardem - są napisane w C (czy raczej makrach preprocesora).
Ale też uważam, że są ok.
Jednak interesuje mnie w tej kwestii zdanie Pierdolisza Głupotego, bo to on wydaje się mieć jakieś obiekcje.

 można dorzucić dwa oczywiste fakty:
> 1) Pisanie czegoś samemu jest bardziej ryzykowne niż używanie 
>    dobrze przetestowanych bibliotek.

No, przykłady mamy na każdym kroku - takie jak np. Heartbleed.

> 2) Taki prosty asert (bez pisania czegoś samemu) z biblioteki ma za mało
>    funkcjonalności do której się przyzwyczaiłem.
> 
> Więc niech każdy, zgodnie z ideą elastyczności C++, wybierze co dla niego
> lepsze. Albo używaj skąpych gotowców, albo zaryzykuj napisanie bardziej
> rozbudowanych asercji.

Jeżeli idzie o nagłówek assert.h, to myślę, że nawet jeśli by powierzyć jego analizę Pierdoliszowi Głupotemu, to by sobie poradził.

W dniu piątek, 6 września 2019 17:06:15 UTC+2 użytkownik AK napisał:
> On 2019-09-06 10:33, Mateusz Viste wrote:
> > On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
> >> A uzasadnienia i tak i tak nie będzie.
> > 
> > AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
> > widziałem by kiedykolwiek sam cokolwiek mądrego napisał.
> 
> Piszę same mądre (czyli prawdziwe) rzeczy :).
> Nie moja wina, że głupcy ich nie dostrzegają.

A może jednak Twoja, Pierdoliszu.
Może gdybyś był prawdziwie mądry, umiałbyś pisać swoje rzeczy w taki sposób, żeby ci biedni głupcy potrafili ujrzeć blask Twej mądrości.

Może jestem głupcem, ale niestety nie umiem dostrzec w Twoich wypowiedziach niczego więcej poza banalnymi płytkimi opiniami.

Opiniami, których nie raczysz uzasadnić nam, maluczkim, tylko serwujesz je ex cathedra jak wyrocznia. Opiniami, których rzeczowości nie ma nawet jak sprawdzić.

A kiedy ja, kaleka umysłowy, próbuję sformułować myśl, to Ty, Pierdoliszu, zamiast próbować ją jakoś zinterpretować, zamiast pomóc mi sformułować ją tak, żeby miała sens dla nas obu, stwierdzasz, że "pieprzę 3po3", w czym mój pożałowania godny zawistny umysł doszukuje się takiej ewentualności, że może dlatego wydaje Ci się, że "pieprzę 3po3", że sam nie jesteś w stanie moich słów zinterpretować, i dlatego wolisz je zdyskredytować.

On Friday, September 6, 2019 at 9:12:39 PM UTC+2, Mateusz Viste wrote:
> On Fri, 06 Sep 2019 12:03:02 -0700, Maciej Sobczak wrote:
> > Obowiązek zapewnienia 100% pokrycia istnieje dla *całego*
> > kodu a nie tylko dla jakiegoś drobnego kawałka, który napisałeś sam, a
> > pokrywanie kodu jakiejś obcej biblioteki albo wykazywanie jej zgodności
> > z wymaganiami projektu to jest coś, czego nikt nie chciałby robić.
> 
> W tym momencie zdałem sobie sprawę, że myślimy o całkiem innych rzeczach 
> - tzn. ty piszesz o tworze dużo bardziej ekstremalnym niż założyłem (co 
> jest zupełnie zgodne z pierwotnym tematem "NASA").
> 
> No i faktycznie - jeśli przyjąć, że piszemy logikę kontrolera stacji 
> orbitalnej Jowisza, to "normalne" programowanie odpada. 

Nie odpada. Oprogramowanie do kontroli stacji kosmicznej na której 
miałoby przebywać choćby milion ludzi, też ma elementy bardziej i mniej 
krytyczne. Błędy w tych mniej krytycznych czasami można skorygować w
trakcie działania. Ale 'jądro' takich systemów i niektóre jego 
części faktycznie najlepiej zrobić od zera, obłożyć testami, dać
matematykom do analizy, itd...


> Zostaje pisanie 
> pod "bare metal", gdzie program musi być wrzucony pod ściśle określony 
> adres, każda zmienna ma ściśle określone miejsce w pamięci, 

To ma zaletę i wadę. Po pierwsze jest zaleta, bo jeśli w fazie testów
zmienne były pod danym adresem, to i w fazie działania będą pod tym
samym adresem. Z drugiej strony jeśli kompilator do każdego testu 
przetasuje adresy przed każdym uruchomieniem, to mogą wyjść ukryte
błędy.

> a sam program 
> jest sprawdzony za pomocą wszystkich możliwych kombinacji danych.

Jeśli procedura działa 1 mikro-sekundę, i pobiera na wejście 32
bity danych, to czas uruchomienia dla wszystkich kombinacji zajmuje
ponad godzinę. Jeśli wyjście procedury zajmuje też 32 bity, to
do kompletnego sprawdzenia potrzebujemy plik o rozmiarze 16GB 
który nie zawiera błędów. Dla procedury która trwa mili-sekundę i
pobiera 64 bity danych, taki proces uruchamiania trwa pół miliona
lat przy użyciu 1000 komputerów! 

Z tego co słyszałem testuje się na wyrywki. Napisanie oprogramowanie 
do sterowania rakietą zlecano ośmiu kompletnie niezależnym zespołom.
Każda wersja procedury jest uruchamiana na tych samych danych
wejściowych. Oczywiście to wszystko nie wystarcza, próbuje się 
udowodnić że kod nie ma błędów, a w trakcie działania jest robione
głosowanie, jeśli 7 wersji danej procedury dało odpowiedź 0, a jedna 
odpowiedź 1, to używa się odpowiedzi 0, a ta procedura która dała 
odpowiedź 1 dostaje mniejszą wagę w do obliczania 'średniej ważonej'.

Pozdrawiam

> Z tego co słyszałem testuje się na wyrywki.

Można, ale to słaba metoda. "Wyrywki" zakładają, że jakiś zbiór jest jednakowo czuły w swoich różnych punktach, co właściwie nigdy nie jest prawdą. Dotyczy to dowolnej konstrukcji inżynierskiej, nie tylko w programowaniu.
Dlatego testuje się równoważne klasy i ich brzegi. Jeśli np. coś ma zakres od 10 do 100, to zamiast zrobić 20 testów na wyrywki lepiej jest zrobić testy np. dla 9, 10, 11, 50, 99, 100, 101.

> Napisanie oprogramowanie 
> do sterowania rakietą zlecano ośmiu kompletnie niezależnym zespołom.

Był kiedyś taki pomysł, ale odchodzi się od niego, bo okazało się, że problemem wcale nie jest poprawność oprogramowania, tylko kompletność wymagań. Po co robić 8 tak samo złych programów? Stosuje się oczywiście redundancję, ale po to, żeby uchronić się przed zjawiskami sprzętowymi. Czyli zobaczysz np. dwa identyczne komputery z *identycznym* oprogramowaniem (czyli jest 1 projekt a nie 8), ale umieszczone w *różnych miejscach* rakiety albo samolotu i to np. pozwala rozwiązać problemy powodowane przez przypadkowe promieniowanie albo zpełnie normalne awarie sprzętu.
Ale pomysł na różne wersje oprogramowania okazał się być nieużyteczny i niepotrzebnie kosztowny.

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

On Saturday, September 7, 2019 at 5:04:15 PM UTC+2, Maciej Sobczak wrote:
> > Z tego co słyszałem testuje się na wyrywki.
> 
> Można, ale to słaba metoda. "Wyrywki" zakładają, że jakiś zbiór jest jednakowo czuły w swoich różnych punktach, co właściwie nigdy nie jest prawdą. Dotyczy to dowolnej konstrukcji inżynierskiej, nie tylko w programowaniu.
> Dlatego testuje się równoważne klasy i ich brzegi. Jeśli np. coś ma zakres od 10 do 100, to zamiast zrobić 20 testów na wyrywki lepiej jest zrobić testy np. dla 9, 10, 11, 50, 99, 100, 101.

Tak, oczywiście. Dawanie danych całkowicie losowo to tak jakby 
punkt wyjścia. Jeśli mamy procedurę która trywialnym algorytmem 
traktuje duży przedział, to warto dla tej procedury zaprojektować 
dane o specjalnym rozkładzie prawdopodobieństwa.

Np.: 

int funkcja( int x, int y ) {
  if( x >= 100 || x <= -100 || y >= 100 || y <= -100 ) {
    return 0;
  }
  return trudne_obliczenia; 
}

To warto częściej losować w 'trudny przedział'.


> 
> > Napisanie oprogramowanie 
> > do sterowania rakietą zlecano ośmiu kompletnie niezależnym zespołom.
> 
> Był kiedyś taki pomysł, ale odchodzi się od niego, 

Z tego co słyszałem z niezależnych źródeł, to tak się robiło. Natomiast 
'sam dla siebie' robiłem tak często, czasami miałem trzy wersje jednej
procedury. Jedna wersja to wersja napisana na szybko po wstępnym 
przemyśleniu, druga to po poprawieniu czytelności, a trzecia to po
optymalizacji - o ile optymalizacja była robiona. Wszystkie wersje 
trzymałem w kodzie:

typ funkcja( argumenty ) {
#ifdef debug
  old_value = old_funkcja( argumenty );
#endif
  // nowy kod
#ifdef debug
  assert( value == old_value );
#endif
  return value;  
}




> bo okazało się, że problemem wcale nie jest poprawność oprogramowania, 
> tylko kompletność wymagań. 

Nie wypowiem się, nie mam tylu danych i doświadczeń aby wyrobić sobie zdanie.


// Po co robić 8 tak samo złych programów? 

Tak to oczywiście nie ma sensu.

> Stosuje się oczywiście redundancję, ale po to, żeby uchronić się przed zjawiskami sprzętowymi. Czyli zobaczysz np. dwa identyczne komputery z *identycznym* oprogramowaniem (czyli jest 1 projekt a nie 8), ale umieszczone w *różnych miejscach* rakiety albo samolotu i to np. pozwala rozwiązać problemy powodowane przez przypadkowe promieniowanie albo zpełnie normalne awarie sprzętu.

Tak, ale na awarie sprzętu taka metoda jest tak jakby standardowa i oczywista.


> Ale pomysł na różne wersje oprogramowania okazał się być 
> nieużyteczny i niepotrzebnie kosztowny.

Czy ja wiem... Jakby od zera do końca projektu prowadzić niezależnie 8 zespołów
to faktycznie drogo i ciężko. Ale jak projekt mamy (prawie) ukończony, to 
nie jest aż tak bardzo kosztowne, aby wybrać z niego kluczowe procedury,
dobrze udokumentować i zlecić napisanie innym zespołom tylko tych procedur.

Mnie się metoda wydaje ciekawa, gdy sam sobie pisałem różne wersje tych
samych procedur, to kilka upierdliwych błędów wychwyciłem, szczególnie na
etapie optymalizacji.

Pozdrawiam

On 2019-09-07 01:48, godek.maciek@gmail.com wrote:
> W dniu piątek, 6 września 2019 17:06:15 UTC+2 użytkownik AK napisał:
>> On 2019-09-06 10:33, Mateusz Viste wrote:
>>> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
>>>> A uzasadnienia i tak i tak nie będzie.
>>>
>>> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
>>> widziałem by kiedykolwiek sam cokolwiek mądrego napisał.
>>
>> Piszę same mądre (czyli prawdziwe) rzeczy :).
>> Nie moja wina, że głupcy ich nie dostrzegają.
> 
> A może jednak Twoja, Pierdoliszu.

No ladnej cie Rodzice kulturki nauczyli :)

> Może gdybyś był prawdziwie mądry, umiałbyś pisać swoje rzeczy w taki sposób, żeby ci biedni głupcy potrafili ujrzeć blask Twej mądrości.

No to jeszcze raz.
Standard C okresla wyraznie, ze aseerty w C "wstawiane sa" (czyli tez 
wykonuja sie) _jedynie_ w trybie debug.
Oczywiscie mozna napisac swoje asserty (tylko po co? Te z assert.h sa
wystarczajace), ale _musza byc one zgodne ze standardem czyli:
1. byc zgodne w sensie API z tymi z assert.h
2. byc z nimi zgodne "semantycznie" i "behawioralnie" (czyli m.in.
_rowniez_ musza byc "wstawiane" w trybie debug.
Bez spelnienia tych zalozen to sa "robotki domowe" a nie asserty w 
sensie jezyka C.

> Może jestem głupcem

"Moze" jest niepotrzebne.

> A kiedy ja, kaleka umysłowy, próbuję sformułować myśl, to Ty, Pierdoliszu, zamiast próbować ją jakoś zinterpretować, zamiast pomóc mi sformułować ją tak, żeby miała sens dla nas obu, stwierdzasz, że "pieprzę 3po3", w czym mój pożałowania godny zawistny umysł doszukuje się takiej ewentualności, że może dlatego wydaje Ci się, że "pieprzę 3po3", że sam nie jesteś w stanie moich słów zinterpretować, i dlatego wolisz je zdyskredytować.

No a co mam powiedziec jesli zwyczajnie "pi..lisz" majac standard C (a 
to _jest wyrocznia_) zwyczajnie w d.. ?

AK

W dniu niedziela, 8 września 2019 08:13:54 UTC+2 użytkownik AK napisał:

> >> Piszę same mądre (czyli prawdziwe) rzeczy :).
> >> Nie moja wina, że głupcy ich nie dostrzegają.
> > 
> > A może jednak Twoja, Pierdoliszu.
> 
> No ladnej cie Rodzice kulturki nauczyli :)

Zwracam się do Ciebie tak, jak mi się przedstawiłeś

> > Może gdybyś był prawdziwie mądry, umiałbyś pisać swoje rzeczy w taki sposób, żeby ci biedni głupcy potrafili ujrzeć blask Twej mądrości.
> 
> No to jeszcze raz.
> Standard C okresla wyraznie, ze aseerty w C "wstawiane sa" (czyli tez 
> wykonuja sie) _jedynie_ w trybie debug.

To jeżeli określa wyraźnie, to może po prostu przytocz tu odpowiedni cytat i będzie po sprawie. Ale jeżeli asercjami nazywasz makra assert (czego standard nie robi), to standard nigdzie nie używa określeń 'wstawiane są' ani 'wykonują się' w odniesieniu do użyć tego makra. Nigdzie też nie mówi, że makro 'assert' jest jedyną dopuszczalną metodą robienia asercji w kodzie.

Jeżeli idzie o makra, to makra co najwyżej 'rozwijane są do'.
I standard mówi jawnie, że jak masz NDEBUG, to makro assert rozwija się do ((void) 0). Nie mówi nic w stylu 'asercja jest wstawiana', bo to programista wstawia asercje, ani 'asercja wykonuje się', bo to niedorzeczność.

> Oczywiscie mozna napisac swoje asserty (tylko po co? Te z assert.h sa
> wystarczajace), ale _musza byc one zgodne ze standardem czyli:
> 1. byc zgodne w sensie API z tymi z assert.h
> 2. byc z nimi zgodne "semantycznie" i "behawioralnie" (czyli m.in.
> _rowniez_ musza byc "wstawiane" w trybie debug.
> Bez spelnienia tych zalozen to sa "robotki domowe" a nie asserty w 
> sensie jezyka C.

Przeoczyłeś chyba moje pytanie o STATIC_ASSERT, Pierdoliszu.

> > Może jestem głupcem
> 
> "Moze" jest niepotrzebne.
> 
> > A kiedy ja, kaleka umysłowy, próbuję sformułować myśl, to Ty, Pierdoliszu, zamiast próbować ją jakoś zinterpretować, zamiast pomóc mi sformułować ją tak, żeby miała sens dla nas obu, stwierdzasz, że "pieprzę 3po3", w czym mój pożałowania godny zawistny umysł doszukuje się takiej ewentualności, że może dlatego wydaje Ci się, że "pieprzę 3po3", że sam nie jesteś w stanie moich słów zinterpretować, i dlatego wolisz je zdyskredytować.
> 
> No a co mam powiedziec jesli zwyczajnie "pi..lisz" majac standard C (a 
> to _jest wyrocznia_) zwyczajnie w d.. ?

Jest sobie słowo. Tym słowem jest 'asercja' w języku polskim (albo 'assertion' po angielsku). To słowo ma swoje określone znaczenie.
Nawet standard C w paru miejscach używa tego słowa w tym znaczeniu.


Otwórz i zobacz sam, Pierdoliszu Głupoty.

https://sjp.pl/asercja

On 2019-09-08 08:58, godek.maciek@gmail.com wrote:

>>> Może jestem głupcem
>>
>> "Moze" jest niepotrzebne.

"Moze" na 100% jest niepotrzebne.

>> No a co mam powiedziec jesli zwyczajnie "pi..lisz" majac standard C (a
>> to _jest wyrocznia_) zwyczajnie w d.. ?
> 
> Jest sobie słowo. Tym słowem jest 'asercja' w języku polskim (albo 'assertion' po angielsku). To słowo ma swoje określone znaczenie.
> Nawet standard C w paru miejscach używa tego słowa w tym znaczeniu.

Ales ty guuupi :)

AK

On Sunday, September 8, 2019 at 8:13:54 AM UTC+2, AK wrote:
> On 2019-09-07 01:48, g@g.m wrote:
> > W dniu piątek, 6 września 2019 17:06:15 UTC+2 użytkownik AK napisał:
> >> On 2019-09-06 10:33, Mateusz Viste wrote:
> >>> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
> >>>> A uzasadnienia i tak i tak nie będzie.
> >>>
> >>> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
> >>> widziałem by kiedykolwiek sam cokolwiek mądrego napisał.
> >>
> >> Piszę same mądre (czyli prawdziwe) rzeczy :).
> >> Nie moja wina, że głupcy ich nie dostrzegają.
> > 
> > A może jednak Twoja, Pierdoliszu.
> 
> No ladnej cie Rodzice kulturki nauczyli :)

Czas nie jest z gumy, ten czas który straciliście na tę czy inną 
awanturę już jest stracony, już w tym czasie nic dobrego nie zrobicie. 

 
> > Może gdybyś był prawdziwie mądry, umiałbyś pisać swoje rzeczy w taki sposób, żeby ci biedni głupcy potrafili ujrzeć blask Twej mądrości.
> 
> No to jeszcze raz.
> Standard C okresla wyraznie, ze aseerty w C "wstawiane sa" (czyli tez 
> wykonuja sie) _jedynie_ w trybie debug.

Ale standard nie zabrania pisania swojego dowolnego (byle poprawnego)
kodu diagnostycznego. Z ogólnego tematu pisania absolutnie bezbłędnego
kodu, zabrnęliśmy w straszny szczegół jakim są asercje i to w dodatku
rozmawiamy TYLKO o asercjach z biblioteki standardowej lub ze standardów 
C/C++! Temat tworzenia bezbłędnego kodu jest fascynujący, po co tracić
czas na duperel i szczegół?


> Oczywiscie mozna napisac swoje asserty (tylko po co? Te z assert.h sa
> wystarczajace), 
Jeśli są wystarczające, to znaczy że czegoś nie wiem o standardowych
asercjach. Jak (łatwo i wygodnie) zrobić przy pomocy standardu zrzut do 
pliku logu komplet wszystkiego tego co może być pomocne? Można chyba 
zrzucić wyrażenie (jako string), plik i numer linii. Ja chcę (przynajmniej) 
jeszcze zrzucić datę kompilacji, wersję programu, datę wystąpienia problemu i
co najważniejsze wszystkie wartości zmiennych z funkcji. Poza tym chcę mieć w
logu stos wywołań dla każdego wątku? W Qt mam klasę qdebug:

https://doc.qt.io/qt-5/qdebug.html

QDebug trochę przypomina moje metody logowania i testowania, ale moje są
wygodniejsze, przynajmniej dla mnie.

> ale _musza byc one zgodne ze standardem czyli:
> 1. byc zgodne w sensie API z tymi z assert.h

Jaką zgodność masz na myśli?


> 2. byc z nimi zgodne "semantycznie" i "behawioralnie" (czyli m.in.
> _rowniez_ musza byc "wstawiane" w trybie debug.

Oczywiście, po co assert bez wstawiania?


> Bez spelnienia tych zalozen to sa "robotki domowe" a nie asserty w 
> sensie jezyka C.

Ehhh.


> > A kiedy ja, kaleka umysłowy, próbuję sformułować myśl, to Ty, Pierdoliszu, zamiast próbować ją jakoś zinterpretować, zamiast pomóc mi sformułować ją tak, żeby miała sens dla nas obu, stwierdzasz, że "pieprzę 3po3", w czym mój pożałowania godny zawistny umysł doszukuje się takiej ewentualności, że może dlatego wydaje Ci się, że "pieprzę 3po3", że sam nie jesteś w stanie moich słów zinterpretować, i dlatego wolisz je zdyskredytować.
> 
> No a co mam powiedziec jesli zwyczajnie "pi..lisz" majac standard C (a 
> to _jest wyrocznia_) zwyczajnie w d.. ?

Można napisać dlaczego ma standard w d. Ale temat standardu to też tylko
(ważny) szczegół tworzenia bezpiecznego oprogramowania.


Pozdrawiam

W dniu niedziela, 8 września 2019 11:20:03 UTC+2 użytkownik AK napisał:

> > Jest sobie słowo. Tym słowem jest 'asercja' w języku polskim (albo 'assertion' po angielsku). To słowo ma swoje określone znaczenie.
> > Nawet standard C w paru miejscach używa tego słowa w tym znaczeniu.
> 
> Ales ty guuupi :)

Bo...?

A, wiem.
"Bo piszę głupoty".

Szkoda mi czasu na taki "poziom argumentacji".

Przykładowo, ISO/IEC 9899:TC3 [http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf], strona 111

EXAMPLE 1 The file scope declarations

    int * restrict a;
    int * restrict b;
    extern int c[];

assert that if an object is accessed using one of a, b, or c, and that object is modified anywhere in the program, then it is never accessed using either of the other two.

Możesz zobaczyć, że pierwszym słowem następującym po fragmencie kodu jest słowo "assert". I mogę Ci podpowiedzieć, że to nie jest makro w C. Frazę "assert that" przetłumaczyłbym w tym miejscu jako "stwierdzają, że".

On 2019-09-08 12:13, godek.maciek@gmail.com wrote:
> W dniu niedziela, 8 września 2019 11:20:03 UTC+2 użytkownik AK napisał:
> 
>>> Jest sobie słowo. Tym słowem jest 'asercja' w języku polskim (albo 'assertion' po angielsku). To słowo ma swoje określone znaczenie.
>>> Nawet standard C w paru miejscach używa tego słowa w tym znaczeniu.
>>
>> Ales ty guuupi :)
> 
> Bo...?
> 
> A, wiem.
> "Bo piszę głupoty".

Tak. To na dole w pełni moją opinię potwierdza.
(zajmij sie filologią a nie programowaniem).

> Szkoda mi czasu na taki "poziom argumentacji".
> 
> Przykładowo, ISO/IEC 9899:TC3 [http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf], strona 111
> 
> EXAMPLE 1 The file scope declarations
> 
>      int * restrict a;
>      int * restrict b;
>      extern int c[];
> 
> assert that if an object is accessed using one of a, b, or c, and that object is modified anywhere in the program, then it is never accessed using either of the other two.
> 
> Możesz zobaczyć, że pierwszym słowem następującym po fragmencie kodu jest słowo "assert". I mogę Ci podpowiedzieć, że to nie jest makro w C. Frazę "assert that" przetłumaczyłbym w tym miejscu jako "stwierdzają, że".
> 

AK

On 2019-09-08 22:17, Maciej Sobczak wrote:
> (nazwijmy je raczej warunkami weryfikacji)

Trafna nazwa!

AK

> Zwykle stosuję słabsze wnioskowanie, np. że z NIE prawdziwości warunków 
> testowych wynika że program jest nie poprawny.

Więc uściślijmy: chodzi o poprawność względem tych warunków, które zostały określone. Czyli jeśli ktoś nie napisał jakiegoś ważnego warunku weryfikacji, to nie może mieć pretensji, że program jest niepoprawny chociaż wszystkie warunki (te niekompletne) są spełnione i narzędzie mu powiedziało, że jest 0 errors, 0 warnings.

Ale też nikt nie twierdzi, że całe zjawisko poprawności należy tak pokryć. Na weryfikację składają się analizy, przeglądy i testy. Warunki poprawności należą do analiz i jeśli nie są kompletne, to uzupełniamy w pozostałych dwóch. Oczywiście, fani metod formalnych dążą do tego, żeby analiza miała jak największy zakres, bo wtedy można oszczędzić gdzie indziej (na testach).

> Tak, to chyba wynika z prawdziwości zdania "kompilator nie ma błędów".

Tak, to ciekawa uwaga. Jeżeli zakładamy, że kompilator może mieć błędy, to analizy kodu źródłowego nie wystarczają, i tak trzeba mieć komplet testów (i to jest argument przeciwko analizom).

> do składni w adnotacjach bym musiał przywyknąć.

Jak do każdej innej. Faktem jest, że ASCII nie bardzo ma coś do zaoferowania gdy w grę wchodzą bardziej skomplikowane zapisy i się robi sieczka. Dlatego osobiście widzę tu miejsce na integrację z narzędziami takimi jak Mathematica.

> Abs i sortowanie stanowią stosunkowo łatwe przykłady.

Sortowanie to jeden z najtrudniejszych przykładów w ogóle. Nie wystarczy pokazać, że elementy są w dobrej kolejności, trzeba jeszcze pokazać, że to są właściwe elementy (że żaden nie zginął albo nie pojawił z czapy).

> Zwykle nie wiem 
> jak mam zrobić warunki, gdy mam okienko dialogowe np. z 20ma polami i
> piszę parser czy użytkownik nie wpisał blędnych wartości? Czy parser 
> przepuści jakiś przypadek błędnych danych wejściowych dla programu? 
> Niby sam parser jest takim warunkiem, działa na zasadzie: dane złe, to
> warunek je wychwyci.

Dobry przykład. Wtedy można zmienić myślenie z "wychwyć złe wartości" na "akceptuj dobre wartości", czasem to ułatwia projektowanie.

> > I teraz ciekawostka: asercja napisana przy użyciu makra "assert" może być
> > traktowana jako warunek do wykazania *oraz* jako nowe założenie dla 
> > dalszych rozważań. 
> 
> O jakie założenie i o jakie rozważania chodzi?

void foo()
{
    // część 1
    // ...

    assert(x > 0); // VC_1

    // część 2
    // ...

    assert(x > 0); // VC_2
}

Pierwszy warunek sprawdza, czy część 1 jest poprawna a drugi warunek sprawdza część 2. Ten drugi warunek polega na wiedzy (założeniu) z warunku pierwszego, czyli zakładamy, że na początku części 2 jest x > 0, bo mamy taką "gwarancję". I jeśli z części 2 wynika, że *przy takim założeniu nadal* jest x > 0, to wtedy cieszymy się, że część 2 jest poprawna.

I teraz może się okazać, że nie umiemy wykazać VC_1, bo jest to zbyt trudne (powiedzmy, że wtedy pokrywamy to testami). Ale jeśli VC_2 jest spełnione, to nadal wiemy, że część 2 jest poprawna.
To jest forma długu technicznego, bo jeśli się okaże (np. w testach), że jednak część 1 jest niepoprawna, to nasza analiza części 2 jest nic nie warta, bo opierała się na błędnych założeniach. Ale taki dług można podjąć i tak się robi.

Oczywiście mówimy o analizach statycznych, nie o run-time'owym assercie.

> Nie używałem assume.

Bo w run-time to nie ma sensu, więc tego normalnie w C/C++ nie ma.
Ale zobacz tutaj:

https://docs.adacore.com/spark2014-docs/html/ug/en/source/assertion_pragmas.html#pragma-assume

Assume piszemy wtedy, gdy wiemy coś, czego w kodzie nie widać.

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