Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #32905 > unrolled thread
| Started by | Roman Tyczka <noemail@because.no> |
|---|---|
| First post | 2019-08-30 09:09 +0200 |
| Last post | 2019-09-04 18:00 +0200 |
| Articles | 20 on this page of 97 — 11 participants |
Back to article view | Back to pl.comp.programming
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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-09-04 10:54 -0700 |
| Message-ID | <a08139d2-95a7-4568-b224-282cfede80b5@googlegroups.com> |
| In reply to | #32971 |
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.
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-04 21:07 +0200 |
| Message-ID | <88ce0ee3-a454-e3c8-e800-3eabc7ae41eb@nowhere.net> |
| In reply to | #32974 |
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
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-09-04 14:05 -0700 |
| Message-ID | <1a7664a9-c081-49f9-94a1-941aad8b3b73@googlegroups.com> |
| In reply to | #32975 |
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. ?
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2019-09-05 04:37 -0700 |
| Message-ID | <2fba1931-e3c9-49ed-803a-ec426628dc6d@googlegroups.com> |
| In reply to | #32976 |
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
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-06 07:31 +0200 |
| Message-ID | <qksqus$1h0q$1@gioia.aioe.org> |
| In reply to | #32976 |
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
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2019-09-06 01:12 -0700 |
| Message-ID | <32d9851d-60a0-4091-8a02-d51d326b9638@googlegroups.com> |
| In reply to | #32982 |
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!
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-09-06 08:33 +0000 |
| Message-ID | <5d7219bc$0$6446$426a74cc@news.free.fr> |
| In reply to | #32984 |
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
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2019-09-06 03:06 -0700 |
| Message-ID | <04fbf8a6-3ae6-40b9-9c45-7787fcf7b01f@googlegroups.com> |
| In reply to | #32985 |
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
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-09-06 10:57 +0000 |
| Message-ID | <5d723b8c$0$6468$426a74cc@news.free.fr> |
| In reply to | #32986 |
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
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-09-06 06:42 -0700 |
| Message-ID | <8dfd1225-31c1-4200-ba74-06c68f0ca768@googlegroups.com> |
| In reply to | #32986 |
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
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-09-06 14:06 +0000 |
| Message-ID | <5d7267e0$0$15200$426a34cc@news.free.fr> |
| In reply to | #32988 |
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
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-09-06 12:03 -0700 |
| Message-ID | <583331c9-7611-4abe-a5e1-6a1a885b88bb@googlegroups.com> |
| In reply to | #32989 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-09-06 19:12 +0000 |
| Message-ID | <5d72afa6$0$3531$426a74cc@news.free.fr> |
| In reply to | #32996 |
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
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2019-09-07 01:55 -0700 |
| Message-ID | <37e18be5-8ace-4584-8cf6-79952b8a1995@googlegroups.com> |
| In reply to | #32997 |
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
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-09-07 08:04 -0700 |
| Message-ID | <13b39048-17a0-431b-bce2-1bac7e6399bc@googlegroups.com> |
| In reply to | #33002 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2019-09-07 10:35 -0700 |
| Message-ID | <94c2a92d-a0f2-45c4-aebf-2f0db494760d@googlegroups.com> |
| In reply to | #33003 |
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
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-06 17:06 +0200 |
| Message-ID | <qktsl4$c9i$1@gioia.aioe.org> |
| In reply to | #32985 |
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
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-09-06 16:48 -0700 |
| Message-ID | <dad26053-c63d-4ecd-a8de-3034ca8abaa0@googlegroups.com> |
| In reply to | #32990 |
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ć.
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-09-08 08:13 +0200 |
| Message-ID | <ql2670$188e$1@gioia.aioe.org> |
| In reply to | #33001 |
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
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-09-07 23:58 -0700 |
| Message-ID | <4e3d526f-791b-4e47-a9e6-6184673735b0@googlegroups.com> |
| In reply to | #33007 |
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
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | pl.comp.programming
csiph-web