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

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

Jak to robią w NASA

Started byRoman Tyczka <noemail@because.no>
First post2019-08-30 09:09 +0200
Last post2019-09-04 18:00 +0200
Articles 20 on this page of 97 — 11 participants

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

Contents

  Jak to robią w NASA Roman Tyczka <noemail@because.no> - 2019-08-30 09:09 +0200
    Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-08-30 07:20 +0000
      Re: Jak to robią w NASA Roman Tyczka <noemail@because.no> - 2019-08-30 12:27 +0200
        Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-08-30 11:09 +0000
          Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 18:42 +0200
            Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-01 10:01 +0200
          Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 18:52 +0200
        Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 19:43 +0200
      Re: Jak to robią w NASA bartekltg <bartekltg@gmail.com> - 2019-09-04 07:39 -0700
    Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-08-30 08:06 +0000
      Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-08-30 12:49 +0000
        Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 19:17 +0200
        Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-08-31 13:14 -0700
          Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 22:44 +0200
            Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-08-31 13:54 -0700
            Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-08-31 14:15 -0700
          Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-09-01 17:21 +0000
        Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-09-01 17:17 +0000
      Re: Jak to robią w NASA Adam Klobukowski <adamklobukowski@gmail.com> - 2019-08-30 10:20 -0700
        Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-09-01 17:23 +0000
    Re: Jak to robią w NASA Wojciech Muła <wojtek.mula@gmail.com> - 2019-08-30 10:21 -0700
      Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 19:21 +0200
      Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-01 10:05 +0200
        Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-09-04 17:38 +0200
          Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:10 +0200
    Re:Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 20:03 +0200
      Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-01 13:55 -0700
        Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-02 08:30 +0200
          Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-02 05:16 -0700
            Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-02 21:33 +0200
              Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-03 00:42 -0700
                Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 18:34 +0200
              Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 01:58 -0700
                Re: Jak to robią w NASA Roman Tyczka <noemail@because.no> - 2019-09-03 16:28 +0200
                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 11:49 -0700
                    Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-03 12:33 -0700
                      Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-04 00:31 -0700
                        Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-04 00:53 -0700
                          Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:04 +0200
                            Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:07 +0200
                            Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-04 10:54 -0700
                              Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 21:07 +0200
                                Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-04 14:05 -0700
                                  Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-05 04:37 -0700
                                  Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-06 07:31 +0200
                                    Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 01:12 -0700
                                      Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 08:33 +0000
                                        Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 03:06 -0700
                                          Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 10:57 +0000
                                          Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-06 06:42 -0700
                                            Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 14:06 +0000
                                              Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-06 12:03 -0700
                                                Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 19:12 +0000
                                                  Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-07 01:55 -0700
                                                    Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-07 08:04 -0700
                                                      Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-07 10:35 -0700
                                        Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-06 17:06 +0200
                                          Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 16:48 -0700
                                            Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-08 08:13 +0200
                                              Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-07 23:58 -0700
                                                Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-08 11:19 +0200
                                                  Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-08 03:13 -0700
                                                    Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-09 17:56 +0200
                                              Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-08 02:36 -0700
                                      Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-06 17:11 +0200
                                        Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 09:22 -0700
                                    Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 10:14 -0700
                                      Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 11:28 -0700
                                        Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 14:59 -0700
                          Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-04 14:49 -0700
                            Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 09:29 -0700
                              Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-06 12:25 -0700
                                Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 14:00 -0700
                                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-07 08:21 -0700
                                    Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-07 15:18 -0700
                                      Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-08 08:32 -0700
                                      Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-08 13:17 -0700
                                        Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-10 22:30 -0700
                                          Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-11 00:21 -0700
                                            Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-11 11:32 -0700
                                              Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-12 00:21 -0700
                                                Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-12 03:05 -0700
                                                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-12 23:14 -0700
                                        Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-11 20:09 +0200
                      Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:00 +0200
                Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 18:35 +0200
                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 11:51 -0700
                    Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 18:43 +0200
                Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 18:43 +0200
                  Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-03 11:04 -0700
                    Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 20:26 +0200
                      Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-03 23:32 -0700
                        Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 18:52 +0200
                          Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-05 00:20 -0700
                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 12:05 -0700
                Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-09-04 18:11 +0200
        Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-09-04 18:00 +0200

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#32912

FromWojciech Muła <wojtek.mula@gmail.com>
Date2019-08-30 10:21 -0700
Message-ID<3f8295be-30ab-40d7-a05b-a80e1a5d01d5@googlegroups.com>
In reply to#32905
On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:
> https://fossbytes.com/nasa-coding-programming-rules-critical/

Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-stuff

BTW "All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting." używamy, polecam (-Werror jest, wbrew pozorom, wicej niż korzystne)

w.

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

#32918

Fromslawek <x.y@org.org>
Date2019-08-31 19:21 +0200
Message-ID<qkeaai$2n9$2@news.icm.edu.pl>
In reply to#32912
Wojciech Muła <wojtek.mula@gmail.com> Wrote in message:
> On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:> https://fossbytes.com/nasa-coding-programming-rules-critical/Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-stuffBTW "All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting." używamy, polecam (-Werror jest, wbrew pozorom, wicej niż korzystne)w.

True.


Jednakże...

 Koncepcje kompilacji, błędów kompilacji itp. to trochę zramolałe są.


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

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

#32929

FromAK <nobody@nowhere.net>
Date2019-09-01 10:05 +0200
Message-ID<07cec5c4-79b7-eebf-c55d-ea8f571dcef8@nowhere.net>
In reply to#32912
On 2019-08-30 19:21, Wojciech Muła wrote:
> On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:
>> https://fossbytes.com/nasa-coding-programming-rules-critical/
> 
> Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-stuff
> 
> BTW "All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting." używamy, polecam (-Werror jest, wbrew pozorom, wicej niż korzystne)

Eee... Co to są compile warnings? Znam tylko compile errors :(
Slowem b.dobra zasada.

AK

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

#32965

Fromslawek <x.y@org.org>
Date2019-09-04 17:38 +0200
Message-ID<qkolqk$30j$1@news.icm.edu.pl>
In reply to#32929
AK <nobody@nowhere.net> Wrote in message:
> On 2019-08-30 19:21, Wojciech Muła wrote:> On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:>> https://fossbytes.com/nasa-coding-programming-rules-critical/> > Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-stuff> > BTW "All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting." używamy, polecam (-Werror jest, wbrew pozorom, wicej niż korzystne)Eee... Co to są compile warnings? Znam tylko compile errors :(Slowem b.dobra zasada.AK

I tak, i nie.

Nigdy nie zrozumiem dlaczego MS walczy z POSIX i np. utrudnia 
 używanie kbhit(), uważając że tylko _kbhit() jest
 koszerne.


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

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

#32973

FromAK <nobody@nowhere.net>
Date2019-09-04 19:10 +0200
Message-ID<qkor5n$1fvu$1@gioia.aioe.org>
In reply to#32965
On 2019-09-04 17:38, slawek wrote:
> I tak, i nie.
> 
> Nigdy nie zrozumiem dlaczego MS walczy z POSIX i np. utrudnia
>   używanie kbhit(), uważając że tylko _kbhit() jest
>   koszerne.

Bo tak (niestety) nakazuje ANSI.
Od zawsze ANSI jest w konflikcie z Posix.
PS: Np. Borland trzymal sie bardziej Posix (kbhit), a MS od pewnego
     (b.dawnego) czasu bardziej ANSI.

AK

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

#32921

Fromslawek <x.y@org.org>
Date2019-08-31 20:03 +0200
Message-ID<qkecqc$c03$1@news.icm.edu.pl>
In reply to#32905
Roman Tyczka <noemail@because.no> Wrote in message:
> https://fossbytes.com/nasa-coding-programming-rules-critical/-- pozdrawiamRoman Tyczka


Ciekawe jest to czego w tym nie ma:

1. Architektura i wzorce projektowe.
2. Statyczna analiza kodu.
3. Testy jednostkowe i integracyjne.
4. Dokumentacja.
5. Audyt. XP
6. Metodyka (waterfall ?!?)

Ot, bajeczki dla nastolatków.





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

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

#32933

FromMaciej Sobczak <see.my.homepage@gmail.com>
Date2019-09-01 13:55 -0700
Message-ID<3ec85b36-33be-49bd-b688-d8c9213a771a@googlegroups.com>
In reply to#32921
> > https://fossbytes.com/nasa-coding-programming-rules-critical/
> 
> Ot, bajeczki dla nastolatków.

Nie, po prostu ktoś sobie na blogu napisał. Najprostszy standard kodowania MISRA-C ma 230 stron, ostatnio opublikowany z AUTOSAR dla C++ ma 370 stron. Ten blog nie porusza nawet wierzchołka zagadnienia.

Ogólnie, to nie są jakieś dziwne reguły, właśnie takich należy się spodziewać.
Warto też pamiętać, że pomimo wysokiej popularności 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. Tzn. oni oczywiście dbają o pieniądze podatnika (w sensie - szkoda stracić drogą rakietę) i o swoją reputację (w sensie - jak ją stracą, to kolejnego projektu mogą nie mieć), ale poza tymi dwoma wartościami nie mają o co dbać, bo w szczególności pilot rakiety jest w oczach opinii publicznej bardziej żołnierzem, niż obywatelem, więc jego strata jest przez publiczność postrzegana jako godna ofiara na ołtarzu postępu. Przecież wiedział, że może zginąć, nie?

Inaczej mówiąc 1: publiczna akceptacja fakapu w tej branży jest całkiem wysoka, w odróżnieniu od dziedzin, gdzie się zabija niewinnych obywateli.

Inaczej mówiąc 2: pomimo tego, że te kilka reguł wygląda strasznie dla "normalnego" programisty, to typowy projekt NASA mógłby nie przejść rygoru obowiązującego w lotnictwie cywilnym. No, serio, nie wystarczy mieć funkcje krótsze niż 60 linijek, żeby przejść przez proces certyfikacji[*].

[*] Który to proces właśnie traci reputację przez ostatnie lotnicze fakapy. Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.

> Ciekawe jest to czego w tym nie ma:
> 
> 1. Architektura i wzorce projektowe.
> 2. Statyczna analiza kodu.
> 3. Testy jednostkowe i integracyjne.
> 4. Dokumentacja.
> 5. Audyt. XP
> 6. Metodyka (waterfall ?!?)

Ale chyba nie o tym był ten blog. Natomiast warto zauważyć, że standard kodowania jest właśnie po to, żeby zrobić punkt 2 powyżej i żeby sobie ułatwić osiągnięcie jeszcze kilku innych celów jakościowych. I tylko po to. Gorzej, że z powodu takich blogów ludzie potem myślą, że standard kodowania jest jedyną rzeczą, która odróżnia proces krytyczny od "normalnego" i tylko na nim się skupiają. Tymczasem te "straszne" reguły to jest najmniejszy problem. Klepanie kodu to tylko kilka procent wysiłku, nawet z tymi strasznymi regułami.
Więc bez przesady.

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

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

#32935

FromAK <nobody@nowhere.net>
Date2019-09-02 08:30 +0200
Message-ID<qkicu0$knb$1@gioia.aioe.org>
In reply to#32933
On 2019-09-01 22:55, Maciej Sobczak wrote:

> Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.

Hehe. Smiechu warte.

AK

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

#32936

FromMaciej Sobczak <see.my.homepage@gmail.com>
Date2019-09-02 05:16 -0700
Message-ID<46e56026-21be-4761-908e-7991c72a1143@googlegroups.com>
In reply to#32935
> > Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.
> 
> Hehe. Smiechu warte.

O, fajna dyskusja będzie. Dlaczego śmiechu warte?

Zanim się rozpędzisz, mały hint: nie napisałem, że takich reguł powinno być jeszcze więcej, albo że funkcje powinny być jeszcze krótsze. Ale nadal twierdzę, że trzeba być bardziej jeszcze bardziej rygorystycznym.
No więc dlaczego śmiechu warte?

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

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

#32940

FromAK <nobody@nowhere.net>
Date2019-09-02 21:33 +0200
Message-ID<qkjqqi$1b59$1@gioia.aioe.org>
In reply to#32936
On 2019-09-02 14:16, Maciej Sobczak wrote:
>>> Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.
>>
>> Hehe. Smiechu warte.
> 
> O, fajna dyskusja będzie. Dlaczego śmiechu warte?
> 
> Zanim się rozpędzisz, mały hint: nie napisałem, że takich reguł powinno być jeszcze więcej, albo że funkcje powinny być jeszcze krótsze. Ale nadal twierdzę, że trzeba być bardziej jeszcze bardziej rygorystycznym.

Tak, ale w inny - normalny sposob (wyjasnien nizej).

> No więc dlaczego śmiechu warte?

Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
(niech to nawet będzie Misra-C/C++, ale jako _jezyk_ a nie zwykle
chore C/C++ z setkami reguł ktore rudno zpamietac, a co dopiero stosowac
(wiem wiem, Parasofty itp super na tym syfie zarabiaja:), albo po prostu
"odkurzyć" i ulepszyć Adę - czy nawet Modulę2 (tak tak wiem - M2 to
bardziej real-time niz safety) to na siłę trzyma się tych C/C++ czyli
języków _skrajnie_ nie nadających się do tzw. "bezpiecznego"
programowania.

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

AK

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

#32945

From"M.M." <mmarszik@gmail.com>
Date2019-09-03 00:42 -0700
Message-ID<7f84db6a-7be1-42c7-b959-c17132373fc0@googlegroups.com>
In reply to#32940
On Monday, September 2, 2019 at 9:33:41 PM UTC+2, AK wrote:
> On 2019-09-02 14:16, Maciej Sobczak wrote:
> >>> Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.
> >>
> >> Hehe. Smiechu warte.
> > 
> > O, fajna dyskusja będzie. Dlaczego śmiechu warte?
> > 
> > Zanim się rozpędzisz, mały hint: nie napisałem, że takich reguł powinno być jeszcze więcej, albo że funkcje powinny być jeszcze krótsze. Ale nadal twierdzę, że trzeba być bardziej jeszcze bardziej rygorystycznym.
> 
> Tak, ale w inny - normalny sposob (wyjasnien nizej).
> 
> > No więc dlaczego śmiechu warte?
> 
> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
> (niech to nawet będzie Misra-C/C++, ale jako _jezyk_ a nie zwykle
> chore C/C++ z setkami reguł ktore rudno zpamietac, a co dopiero stosowac
> (wiem wiem, Parasofty itp super na tym syfie zarabiaja:), albo po prostu
> "odkurzyć" i ulepszyć Adę - czy nawet Modulę2 (tak tak wiem - M2 to
> bardziej real-time niz safety) to na siłę trzyma się tych C/C++ czyli
> języków _skrajnie_ nie nadających się do tzw. "bezpiecznego"
> programowania.
> 
> 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... :(

Moim zdaniem dobry C++ w rękach dobrego (niekoniecznie bardzo dobrego)
programisty od jakiegoś czasu już nadaje się do bezpiecznego 
programowania.

Pozdrawiam

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

#32949

FromAK <nobody@nowhere.net>
Date2019-09-03 18:34 +0200
Message-ID<qkm4m5$1ila$1@gioia.aioe.org>
In reply to#32945
On 2019-09-03 09:42, M.M. wrote:
> Moim zdaniem dobry C++ w rękach dobrego (niekoniecznie bardzo dobrego)
> programisty od jakiegoś czasu już nadaje się do bezpiecznego
> programowania.

Zwyczajnie bzdużysz/mylisz się o 180st.

AK

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

#32947

FromMaciej Sobczak <see.my.homepage@gmail.com>
Date2019-09-03 01:58 -0700
Message-ID<0125b7f3-d337-4537-a6d3-237b78065215@googlegroups.com>
In reply to#32940
> 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.

> (niech to nawet będzie Misra-C/C++, ale jako _jezyk_ a nie zwykle
> chore C/C++ z setkami reguł ktore rudno zpamietac, a co dopiero stosowac
> (wiem wiem, Parasofty itp super na tym syfie zarabiaja:), albo po prostu
> "odkurzyć" i ulepszyć Adę - czy nawet Modulę2 (tak tak wiem - M2 to
> bardziej real-time niz safety) to na siłę trzyma się tych C/C++ czyli
> języków _skrajnie_ nie nadających się do tzw. "bezpiecznego"
> programowania.

Masz rację. Ale problem polega na tym, że to właśnie programiści (ogólnie: przemysł) trzymają się tych języków. Przemysł jest zdumimewająco odporny na zmiany w tej dziedzinie, więc jedyne, co można przemysłowi zaproponować, to dokręcanie śruby na tym, co mają. Dlatego powstają standardy kodowania.

I bez przesady z tymi regułami, których się nie da zapamiętać. Wystarczy zrozumimeć, skąd się wzięły, wtedy nie trzeba ich już pamiętać, bo ich stosowanie staje się naturalne. Naprawdę, musisz pamiętać regułę o niestosowaniu goto, żeby nie stosować? Ja nie stosowałem zanim się dowiedziałem, że jest taka reguła gdzieś w jakimś standardzie.

Natomiast prawdą jest też, że są reguły, które faktycznie nie pasują do rzeczywistości. Mnie na tej liście uderzyła reguła, że w kodzie ma być ileś tam assertów. Nie mniej i nie więcej, tylko ileś tam. Bzdura jakaś.
Na szczęście MISRA nie ma takiej reguły. Ani w AUTOSAR. I to też pokazuje, że NASA nie jest wcale wyznacznikiem najlepszej praktyki. Albo ten blog jest od czapy, to też możliwe.

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

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

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

#32948

FromRoman Tyczka <noemail@because.no>
Date2019-09-03 16:28 +0200
Message-ID<rmvauunflug0.dlg@tyczka.com>
In reply to#32947
On Tue, 3 Sep 2019 01:58:01 -0700 (PDT), Maciej Sobczak wrote:

> Natomiast prawdą jest też, że są reguły, które faktycznie nie pasują do
> rzeczywistości. Mnie na tej liście uderzyła reguła, że w kodzie ma być
> ileś tam assertów. Nie mniej i nie więcej, tylko ileś tam. Bzdura jakaś.
> Na szczęście MISRA nie ma takiej reguły. Ani w AUTOSAR. I to też
> pokazuje, że NASA nie jest wcale wyznacznikiem najlepszej praktyki. Albo
> ten blog jest od czapy, to też możliwe.

Z asercjami nie jest napisane, że ni mniej ni więcej niż 2, tylko że co
najmniej dwie na funkcję, czyli nie ma górnego limitu.
Inna sprawa, że to pełnej sensowności tej regule nie nadaje.

-- 
pozdrawiam
Roman Tyczka

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

#32957

FromMaciej Sobczak <see.my.homepage@gmail.com>
Date2019-09-03 11:49 -0700
Message-ID<eab71553-8760-428b-a4aa-a58ac0f346ec@googlegroups.com>
In reply to#32948
> Z asercjami nie jest napisane, że ni mniej ni więcej niż 2, tylko że co
> najmniej dwie na funkcję, czyli nie ma górnego limitu.
> Inna sprawa, że to pełnej sensowności tej regule nie nadaje.

Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli. Nawet jeśli przyjmiemy założenie, że źle działający program należy zabić na miejscu, to nie można obowiązku zabijania nałożyć na ten sam program, o którym właśnie mówimy, że źle działa. To jest bez sensu. Monitor/strażnik, jeśli już, musi być niezależnym bytem.

To, że MISRA-C i AUTOSAR nawet nie wspominają o asercjach nie jest przypadkiem. A to, że AUROSAR wspomina o static_assert też nie jest przypadkiem, bo wykrycie czegoś w czasie kompilacji, czyli przed uruchomieniem, akurat ma sens.

Więc zalecanie, żeby funkcja miała co najmniej dwie asercje, to jakaś pomyłka.

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

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

#32960

Fromgodek.maciek@gmail.com
Date2019-09-03 12:33 -0700
Message-ID<1794fcdb-d7bb-402f-927f-80010b217989@googlegroups.com>
In reply to#32957
W dniu wtorek, 3 września 2019 20:49:52 UTC+2 użytkownik Maciej Sobczak napisał:
> > Z asercjami nie jest napisane, że ni mniej ni więcej niż 2, tylko że co
> > najmniej dwie na funkcję, czyli nie ma górnego limitu.
> > Inna sprawa, że to pełnej sensowności tej regule nie nadaje.
> 
> Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli. 

Co za bzdura.

Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne przekonanie, że asercja to "sprawdzenie czegoś w runtimie".

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

#32962

FromMaciej Sobczak <see.my.homepage@gmail.com>
Date2019-09-04 00:31 -0700
Message-ID<1a2f7fe3-5745-40b2-9fd6-868fca99dea5@googlegroups.com>
In reply to#32960
> > Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli. 
> 
> Co za bzdura.
> 
> Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Ale nie równie dobrze, bo komentarze są pożyteczne.
Natomiast asercje to tzw. dead code. Z założenia. To jest kod źródłowy, który pozostawia ślad w kodzie maszynowym, ale którego nie da się pokryć testami. Taki kod jest zabroniony w procesach krytycznych. I tyle.

Powtórzę dla skupienia: MISRA-C i AUTOSAR w ogóle nie poruszają tematu asercji. Co biorąc pod uwagę ilość innych rzeczy, które poruszają, jest co najmniej interesujące.
Otóż rozwiązanie tej zagadki jest bardzo proste: w kodzie krytycznym asercji się nie używa. Bo one stoją w konflikcie z innymi celami, które należy osiągnąć.

> Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Dryfujesz. Komentarze i nazwy są istotne dla czytelności. Mogą być nawet istotne dla śladowania (ang. traceability), wiec czasami nawet nie są sprawą wolnej woli kodera.

Bo jest jeszcze taka możliwość, że potraktujesz asercje jak komentarz. To bardzo dobry pomysł, ale komentarze piszemy w komentarzach.

> Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne przekonanie, że asercja to "sprawdzenie czegoś w runtimie".

Dla pewności sprawdziłem jak to opisuje standard C. Otóż właśnie dokładnie tak.

Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale takie narzędzie potrafi też wyłuskać adnotacje z komentarzy. Więc nadal twierdzę, że te asercje nie powinny być w kodzie.

Natomiast ja chętnie stosuję asercje w skryptach testowych. Nie chce mi się używać wydumanych frameworków do unit testów a w testach asercje pasują idealnie.
Ale nie w kodzie.

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

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

#32963

Fromgodek.maciek@gmail.com
Date2019-09-04 00:53 -0700
Message-ID<a0c6a1c7-e8bf-4079-b5f2-d5dcec42f7d9@googlegroups.com>
In reply to#32962
W dniu środa, 4 września 2019 09:31:05 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli. 
> > 
> > Co za bzdura.
> > 
> > Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.
> 
> Ale nie równie dobrze, bo komentarze są pożyteczne.

Asercje też są pożyteczne.
Asercje są formą komentarza, który dodatkowo można zweryfikować.

> Natomiast asercje to tzw. dead code. Z założenia. To jest kod źródłowy, który pozostawia ślad w kodzie maszynowym, ale którego nie da się pokryć testami.

Asercja to postawa propozycjonalna.
Możesz sobie napisać
#define assert(x) do {} while(0)
i nie masz śladu w kodzie maszynowym.

> Powtórzę dla skupienia: MISRA-C i AUTOSAR w ogóle nie poruszają tematu asercji. Co biorąc pod uwagę ilość innych rzeczy, które poruszają, jest co najmniej interesujące.
> Otóż rozwiązanie tej zagadki jest bardzo proste: w kodzie krytycznym asercji się nie używa. Bo one stoją w konflikcie z innymi celami, które należy osiągnąć.
> 
> > Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.
> 
> Dryfujesz. Komentarze i nazwy są istotne dla czytelności.

Asercje też są istotne dla czytelności.
Po to, żeby programista wiedział:
"aha, ten a ten warunek jest (ma być) tutaj spełniony."
Co może być przydatne przy rozumieniu kodu, jego refaktoryzacji i debugowaniu.

> Bo jest jeszcze taka możliwość, że potraktujesz asercje jak komentarz. To bardzo dobry pomysł, ale komentarze piszemy w komentarzach.

Co jest kiepskim pomysłem, bo błędnego komentarza nie wykryjesz za pomocą narzędzia, a błędną asercję możesz.

> > Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne przekonanie, że asercja to "sprawdzenie czegoś w runtimie".
> 
> Dla pewności sprawdziłem jak to opisuje standard C. Otóż właśnie dokładnie tak.

Asercja nie jest pojęciem wprowadzonym przez standard C.

> Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale takie narzędzie potrafi też wyłuskać adnotacje z komentarzy. 

?

> Więc nadal twierdzę, że te asercje nie powinny być w kodzie.

No to nie dość, że sam błędnie rozumiesz, to jeszcze próbujesz to swoje błędne rozumienie promować.

> Natomiast ja chętnie stosuję asercje w skryptach testowych. Nie chce mi się używać wydumanych frameworków do unit testów a w testach asercje pasują idealnie.
> Ale nie w kodzie.

A skrypty testowe to nie kod?

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

#32971

FromAK <nobody@nowhere.net>
Date2019-09-04 19:04 +0200
Message-ID<qkoqr3$1eec$1@gioia.aioe.org>
In reply to#32963
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

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

#32972

FromAK <nobody@nowhere.net>
Date2019-09-04 19:07 +0200
Message-ID<qkor04$1eec$2@gioia.aioe.org>
In reply to#32971
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

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

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

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

csiph-web