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

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

Jak to robią w NASA

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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#33009

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

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

#33011

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

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

#33014

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

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

#33010

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

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

#32991

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

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

#32992

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

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

#32994

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

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

#32995

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

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

#33000

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

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

#32977

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

Kupa różnych narzędzi weryfikuje adnotacje zaszyte w komentarzach. Statycznie. I tak powinno być.

> Asercja to postawa propozycjonalna.

Możliwe, że pomyliłeś grupy.

> Możesz sobie napisać
> #define assert(x) do {} while(0)

Nie, nie mogę. Zabrania tego zarówno MISRA-C jak i AUTOSAR.
Byłoby łatwiej, gdybyś nie spekulował.

> Asercje też są istotne dla czytelności.

Oczywiście. Ale stanowią dead-code, którego się unika z innych powodów. Być może te powody nie są istotne jak się pisze coś innego gdzieś indziej, ale jeśli mówimy o systemach krytycznych (taki wątek się zrobił), to obowiązują pewne reguły. Dużo reguł. Więcej, niż gdzie indziej. W sumie właśnie od tego spostrzeżenia się ta dyskusja wzięła.

> Asercja nie jest pojęciem wprowadzonym przez standard C.

Standard C definiuje dokładnie, co to pojęcie oznacza w języku C. Może gdzieś indziej oznacza coś innego, albo nawet wcześniej. Nie ma to znaczenia.

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

Ale czego nie rozumiesz? Której części?

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

Dopóki moje rozumienie opiera się na standardach (i to kilku), to będę je promował. Nie do mnie pretensje, nie ja te standardy pisałem.

> A skrypty testowe to nie kod?

Nie musi być. Może to być procedura opisana słownie. Np. w Wordzie. Nie, nie nabijam się. Nieprzypadkiem napisałem wcześniej, że w tej branży klepanie kodu to tylko kilka procent wysiłku.
Natomiast nawet jeśli skrypt testowy będzie kodem w jakimś języku programowania, nawet w tym samym (rzadki przypadek), to tego kodu nie obowiązują takie reguły, jak te dotyczące właściwego kodu programu. Bo i po co.
Dlatego współcześnie popularnym przypadkiem jest użycie Pythona do pisania testów. Tam sobie możesz (a nawet powinieneś) robić asercje ile wlezie.

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

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

#32993

W dniu środa, 4 września 2019 23:49:50 UTC+2 użytkownik Maciej Sobczak napisał:
> > Asercje są formą komentarza, który dodatkowo można zweryfikować.
> 
> Kupa różnych narzędzi weryfikuje adnotacje zaszyte w komentarzach. Statycznie. I tak powinno być.

Dlaczego? Bo właśnie do tego służą komentarze?
Jeżeli tak jest, to to wynika co najwyżej z tego, że macierzysty język jest zbyt słaby, żeby wyrazić te rzeczy, które są istotne (i które weryfikują narzędzia, o których mówisz). I dlatego używa się komentarzy jako takiego "haka" na wyrażanie tych rzeczy.
Bo, jak wskazuje nazwa, komentarze służą do komentowania.

A do stwierdzania faktów służą... stwierdzenia.
(Możesz też poszukać synonimów tego słowa. Wśród nich znajdziesz ...)

> > Asercja to postawa propozycjonalna.
> 
> Możliwe, że pomyliłeś grupy.

Hmm. Nazwa grupy zaczyna się od "pl". Jestem raczej przekonany, że to skrót od "polski" i że sugeruje, że używamy tu znaczeń słów takich, jakie mają w języku polskim.

Słowo "asercja" można nawet znaleźć w Słowniku Języka Polskiego, jeśli komuś chce się szukać.

> > Możesz sobie napisać
> > #define assert(x) do {} while(0)
> 
> Nie, nie mogę. Zabrania tego zarówno MISRA-C jak i AUTOSAR.
> Byłoby łatwiej, gdybyś nie spekulował.

Zabawne to, co mówisz. Zamiast powiedzieć, na przykład:

"nie mogę, bo MISRA C zabrania używania identyfikatorów, które pojawiają się w bibliotece standardowej języka C"

wolisz powiedzieć:

"byłoby łatwiej, gdybyś nie spekulował"

Jakby to faktycznie mogło przybliżyć do rozwiązania jakiegokolwiek problemu.

I otóż, jak napisał powyżej kolega, który przedstawił mi się jako "Pier..lisz Głupoty" (śmieszne nazwisko, swoją drogą), możesz zdefiniować symbol NDEBUG przed załączeniem assert.h.

Albo możesz np. zdefiniować

#define certainly(x) do{}while(0)

Wyjdzie w sumie na to samo.

> > Asercje też są istotne dla czytelności.
> 
> Oczywiście. Ale stanowią dead-code, którego się unika z innych powodów.

Asercje nie stanowią martwego kodu.
Być może strategia obsługi fałszywych asercji, którą przyjmuje biblioteka C (bez NDEBUG) generuje w jakichś okolicznościach martwy kod.

> Być może te powody nie są istotne jak się pisze coś innego gdzieś indziej, ale jeśli mówimy o systemach krytycznych (taki wątek się zrobił), to obowiązują pewne reguły. Dużo reguł. Więcej, niż gdzie indziej. W sumie właśnie od tego spostrzeżenia się ta dyskusja wzięła.
> 
> > Asercja nie jest pojęciem wprowadzonym przez standard C.
> 
> Standard C definiuje dokładnie, co to pojęcie oznacza w języku C. Może gdzieś indziej oznacza coś innego, albo nawet wcześniej. Nie ma to znaczenia.

Standard C mówi wyłącznie, w jaki sposób jest zdefiniowane makro "assert".
Nie mówi nic o tym, co oznacza słowo "asercja".

> > > 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. 
> > 
> > ?
> 
> Ale czego nie rozumiesz? Której części?

Dajmy na to, że mam taki komentarz:

/* wartośc poniższego enuma służą jako indeksy do tablicy TABLICA */

po którym następuje enum.

I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy do tablicy TABLICA?

> > No to nie dość, że sam błędnie rozumiesz, to jeszcze próbujesz to swoje błędne rozumienie promować.
> 
> Dopóki moje rozumienie opiera się na standardach (i to kilku), to będę je promował. Nie do mnie pretensje, nie ja te standardy pisałem.

Nie wiem, jakie standardy czytałeś, ale jeżeli idzie o te, z którymi ja miałem styczność, to żadna nie rościła sobie pretensji do bycia normatywną w kwestii pojęcia asercji.

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

#32998

> > Kupa różnych narzędzi weryfikuje adnotacje zaszyte w komentarzach. Statycznie. I tak powinno być.
> 
> Dlaczego? Bo właśnie do tego służą komentarze?

Powinno być statycznie.
Natomiast komentarze pozwalają "rozszerzyć" język bez ingerowania w kompilator.

> Jeżeli tak jest, to to wynika co najwyżej z tego, że macierzysty język jest zbyt słaby, żeby wyrazić te rzeczy, które są istotne (i które weryfikują narzędzia, o których mówisz). I dlatego używa się komentarzy jako takiego "haka" na wyrażanie tych rzeczy.

Tak. Tak właśnie jest.
Język C jest słaby, więc używa się jego rozszerzeń w komentarzach, żeby wesprzeć jego weryfikację. Zaletą takiego działania jest transparentność względem kompilatora.

> Słowo "asercja" można nawet znaleźć w Słowniku Języka Polskiego, jeśli komuś chce się szukać.

Ale dryfujesz. Napisałem już kilka razy, dlaczego asercji się nie używa a Ty grzebiesz w SJP, żeby... no właśnie nie wiem po co.

> możesz zdefiniować symbol NDEBUG przed załączeniem assert.h.

I w czym mi to pomoże?
Kod, który załaduję na produkcyjne urządzenie musi być *tym samym* kodem, który przetestowałem, co do bitu. Nie ma opcji, żebym zrobił inaczej. Więc ten NDEBUG musiałbym mieć zdefiniowany również w czasie testów.
To na cholerę mi takie asercje?

> Albo możesz np. zdefiniować
> 
> #define certainly(x) do{}while(0)
> 
> Wyjdzie w sumie na to samo.

Mógłbym. Ale po co miałbym definiować makro, któro nic nie robi?

> Asercje nie stanowią martwego kodu.

One są martwe z założenia. Nigdy się nie wykonują, więc są martwe.

> Standard C mówi wyłącznie, w jaki sposób jest zdefiniowane makro "assert".
> Nie mówi nic o tym, co oznacza słowo "asercja".

Dalej nie kumasz. Asercji nie używa się, bo stoją w konflikcie z innymi celami procesów krytycznych. Twoje własne asercje też takie będą, nawet jeśli je będziesz pisał na podstawie SJP.

> Dajmy na to, że mam taki komentarz:
> 
> /* wartośc poniższego enuma służą jako indeksy do tablicy TABLICA */
> 
> po którym następuje enum.
> 
> I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy do tablicy TABLICA?

Jeśli masz takie narzędzie, to sprawdzi.
Czego tu nie rozumiesz?

Przewiń sobie tą stronę i popatrz na komentarze w przykładach:

https://frama-c.com/acsl_tutorial_index.html

> Nie wiem, jakie standardy czytałeś, ale jeżeli idzie o te, z którymi ja miałem styczność, to żadna nie rościła sobie pretensji do bycia normatywną w kwestii pojęcia asercji.

Wniosek jest taki, że czytaliśmy różne standardy.

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

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

#32999

W dniu piątek, 6 września 2019 21:25:18 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Kupa różnych narzędzi weryfikuje adnotacje zaszyte w komentarzach. Statycznie. I tak powinno być.
> > 
> > Dlaczego? Bo właśnie do tego służą komentarze?
> 
> Powinno być statycznie.
> Natomiast komentarze pozwalają "rozszerzyć" język bez ingerowania w kompilator.

Dla ścisłości, formalne wyrażenia zaszyte w komentarzach.
Czyli drugi 'język programowania'. Tylko pewnie z gorszym wsparciem narzędzi.

> > Jeżeli tak jest, to to wynika co najwyżej z tego, że macierzysty język jest zbyt słaby, żeby wyrazić te rzeczy, które są istotne (i które weryfikują narzędzia, o których mówisz). I dlatego używa się komentarzy jako takiego "haka" na wyrażanie tych rzeczy.
> 
> Tak. Tak właśnie jest.
> Język C jest słaby, więc używa się jego rozszerzeń w komentarzach, żeby wesprzeć jego weryfikację. Zaletą takiego działania jest transparentność względem kompilatora.
> 
> > Słowo "asercja" można nawet znaleźć w Słowniku Języka Polskiego, jeśli komuś chce się szukać.
> 
> Ale dryfujesz. Napisałem już kilka razy, dlaczego asercji się nie używa a Ty grzebiesz w SJP, żeby... no właśnie nie wiem po co.

No bo błędnie napisałeś.

> > możesz zdefiniować symbol NDEBUG przed załączeniem assert.h.
> 
> I w czym mi to pomoże?
> Kod, który załaduję na produkcyjne urządzenie musi być *tym samym* kodem, który przetestowałem, co do bitu. Nie ma opcji, żebym zrobił inaczej. Więc ten NDEBUG musiałbym mieć zdefiniowany również w czasie testów.
> To na cholerę mi takie asercje?

Bo po pierwsze, możesz je inaczej interpretować poza swoim procesem.
Po drugie, możesz pewne rzeczy wyrazić w tym samym języku, w którym piszesz program. Po trzecie, na cholerę Ci komentarze? Po czwarte, tak jak masz narzędzia, które parsują formalny język w komentarzach, to mogłyby też tak samo parsować i statycznie weryfikować asercje - bo czemu nie?

> > Albo możesz np. zdefiniować
> > 
> > #define certainly(x) do{}while(0)
> > 
> > Wyjdzie w sumie na to samo.
> 
> Mógłbym. Ale po co miałbym definiować makro, któro nic nie robi?

Po co pisać komentarz, który nic nie robi?

> > Asercje nie stanowią martwego kodu.
> 
> One są martwe z założenia. Nigdy się nie wykonują, więc są martwe.
> 
> > Standard C mówi wyłącznie, w jaki sposób jest zdefiniowane makro "assert".
> > Nie mówi nic o tym, co oznacza słowo "asercja".
> 
> Dalej nie kumasz. Asercji nie używa się, bo stoją w konflikcie z innymi celami procesów krytycznych. Twoje własne asercje też takie będą, nawet jeśli je będziesz pisał na podstawie SJP.
> 
> > Dajmy na to, że mam taki komentarz:
> > 
> > /* wartośc poniższego enuma służą jako indeksy do tablicy TABLICA */
> > 
> > po którym następuje enum.
> > 
> > I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy do tablicy TABLICA?
> 
> Jeśli masz takie narzędzie, to sprawdzi.

Nie mam takiego narzędzia.

> Czego tu nie rozumiesz?

Nie rozumiem w jaki sposób magiczne narzędzia mają nagle czytać moje komentarze ze zrozumieniem. W komentarzach mogę pisać cokolwiek. Jak narzędzie mi sprawdzi, że nie kłamię?

> Przewiń sobie tą stronę i popatrz na komentarze w przykładach:
> 
> https://frama-c.com/acsl_tutorial_index.html

No to wygląda mi na takie rzeczy, które mogę wyrazić w asercjach.

> > Nie wiem, jakie standardy czytałeś, ale jeżeli idzie o te, z którymi ja miałem styczność, to żadna nie rościła sobie pretensji do bycia normatywną w kwestii pojęcia asercji.
> 
> Wniosek jest taki, że czytaliśmy różne standardy.

No to dajesz cytaty.

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

#33004

> > Napisałem już kilka razy, dlaczego asercji się nie używa a Ty grzebiesz w SJP, żeby... no właśnie nie wiem po co.
> 
> No bo błędnie napisałeś.

W jakim sensie błędnie? W takim, że się ich używa?

> > To na cholerę mi takie asercje?
> 
> Bo po pierwsze, możesz je inaczej interpretować poza swoim procesem.

Nie rozumiesz. Nie ma rzeczy poza moim procesem. I nawet nie chodzi o to, że nikt mi za nie nie zapłaci. Chodzi wręcz o to, że ze względów zrozumiałych bardziej dla prawników, niż inżynierów, rzeczy poza procesem są zabronione.

> Po co pisać komentarz, który nic nie robi?

Komentarz nie jest dead-codem. To właśnie ten aspekt sprawia, że asercji się nie używa.

> > > I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy do tablicy TABLICA?
> > 
> > Jeśli masz takie narzędzie, to sprawdzi.
> 
> Nie mam takiego narzędzia.

Spodziewałem się. Ale powinieneś rozumieć, że takie narzędzie można mieć. I ten fakt sprawia, że z takimi argumentami oddalasz się od jakkolwiek rozumianego sukcesu w tej dyskusji.

> W komentarzach mogę pisać cokolwiek.

Dalej nie rozumiesz. Za pisanie czegokolwiek wylatuje się z pracy.
Ale jak napiszesz coś mądrego, to co innego.

> Jak narzędzie mi sprawdzi, że nie kłamię?

Czyli nie zajrzałeś do tego linka, którego podałem do Frama-C. Szkoda.

> > https://frama-c.com/acsl_tutorial_index.html
> 
> No to wygląda mi na takie rzeczy, które mogę wyrazić w asercjach.

Jednak zajrzałeś. Ale nie zrozumiałeś. Tych rzeczy nie da się wyrazić w asercjach języka C - stąd pomysł na taki produkt. Ktoś tego nawet używa.
Być może w innym (hipotetycznym?) języku można by było to mieć w asercjach i bez dodatkowego narzędzia, ale jakoś ten język nie robi furory w tej branży. Więc jest tak, jak pokazałem.

> > Wniosek jest taki, że czytaliśmy różne standardy.
> 
> No to dajesz cytaty.

Czyli nawet w tej warstwie nic nie rozumiesz.
Cytowanie tych standardów jest zabronione. Prawa autorskie i takie tam.

Mógłbym ewentualnie podać numer paragrafu, to jest dozwolone. Ale wtedy musiałbyś sam sobie to otworzyć i przeczytać. No, ale skoro możesz sam otworzyć i przeczytać, to po co mam dawać cytaty? Ctrl-F, "assert", Enter.

No i serio - o co teraz walczysz, tak konkretnie?

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

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

#33006

W dniu sobota, 7 września 2019 17:21:32 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Napisałem już kilka razy, dlaczego asercji się nie używa a Ty grzebiesz w SJP, żeby... no właśnie nie wiem po co.
> > 
> > No bo błędnie napisałeś.
> 
> W jakim sensie błędnie? W takim, że się ich używa?

W takim sensie, jak pisałem na początku.
Czyli odnośnie tego, czym jest asercja w ogóle.
Asercja to uznanie jakiegoś sądu za prawdziwy. Oto znaczenie tego słowa.
Niekiedy tym słowem określa się ślad, jakiego dokonujemy, uznając dany sąd za prawdziwy -- na przykład jeśli w kodzie źródłowym napiszemy

assert(jakiś_sąd)

to takie wyrażenie określamy mianem asercji (ale określamy w sposób metonimiczny).
Natomiast to, że w języku C assert to makro, i że owo makro w pewnych okolicznościach będzie generowało kod sprawdzający prawdziwość owego sądu i w przypadku negatywnego wyniku powodowało wywalenie programu, nie jest asercją.
Pewnie można to nazwać "pewną strategią obsługi asercji fałszu", ale to już się nie mieści w znaczeniu słowa "asercja".

> > > To na cholerę mi takie asercje?
> > 
> > Bo po pierwsze, możesz je inaczej interpretować poza swoim procesem.
> 
> Nie rozumiesz. Nie ma rzeczy poza moim procesem. I nawet nie chodzi o to, że nikt mi za nie nie zapłaci. Chodzi wręcz o to, że ze względów zrozumiałych bardziej dla prawników, niż inżynierów, rzeczy poza procesem są zabronione.

Jest bardzo dużo rzeczy poza Twoim procesem.
Na przykład całe Twoje wcześniejsze doświadczenie.

> > Po co pisać komentarz, który nic nie robi?
> 
> Komentarz nie jest dead-codem. To właśnie ten aspekt sprawia, że asercji się nie używa.

Asercja też nie jest dead-codem. W szczególności jak skompilujesz z -DNDEBUG, to nie jest żadnym kodem.

> > W komentarzach mogę pisać cokolwiek.
> 
> Dalej nie rozumiesz. Za pisanie czegokolwiek wylatuje się z pracy.
> Ale jak napiszesz coś mądrego, to co innego.

Z reguły to nie tak wygląda.
Raczej jest tak, że programista napisze relewantny komentarz, potem inny programista zrefaktoryzuje kod, ale zapomni o aktualizacji komentarza, i komentarz przestaje być relewantny.

> > Jak narzędzie mi sprawdzi, że nie kłamię?
> 
> Czyli nie zajrzałeś do tego linka, którego podałem do Frama-C. Szkoda.
> 
> > > https://frama-c.com/acsl_tutorial_index.html
> > 
> > No to wygląda mi na takie rzeczy, które mogę wyrazić w asercjach.
> 
> Jednak zajrzałeś. Ale nie zrozumiałeś. Tych rzeczy nie da się wyrazić w asercjach języka C

No to spróbujmy pierwszy przykład:

/*@ ensures \result >= x && \result >= y; 
    ensures \result == x || \result == y; 
*/ 
int max (int x, int y) { return (x > y) ? x : y; } 

int max (int x, int y) {
  int result = (x > y) ? x : y;
  assert(result >= x && result >= y);
  assert(result == x || result == y);
  return result;
}

Udało się.

> Ktoś tego nawet używa.
> Być może w innym (hipotetycznym?) języku można by było to mieć w asercjach i bez dodatkowego narzędzia, ale jakoś ten język nie robi furory w tej branży. Więc jest tak, jak pokazałem.
> 
> > > Wniosek jest taki, że czytaliśmy różne standardy.
> > 
> > No to dajesz cytaty.
> 
> Czyli nawet w tej warstwie nic nie rozumiesz.
> Cytowanie tych standardów jest zabronione. Prawa autorskie i takie tam.

,,Czy możemy w swoich pracach korzystać z fragmentów cudzych utworów, a w przypadku roszczeń zasłaniać się dozwolonym użytkiem? Odpowiedź jest prosta i brzmi: tak, jeżeli wykorzystanie fragmentu cudzego utworu, będzie uzasadnione jednym z celów bezpośrednio wskazanych w treści przepisów – „wyjaśnianie, polemika, analiza krytyczna lub naukowa, nauczanie lub prawa gatunku twórczości.”.''
https://prawo.gazetaprawna.pl/artykuly/1127356,opydo-kontra-uniwersal-cytat-czy-naruszenie-praw-autorskich.html

> Mógłbym ewentualnie podać numer paragrafu, to jest dozwolone. Ale wtedy musiałbyś sam sobie to otworzyć i przeczytać. No, ale skoro możesz sam otworzyć i przeczytać, to po co mam dawać cytaty? Ctrl-F, "assert", Enter.

To podaj chociaż tytuły dokumentów.

Ja zaglądałem tutaj:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

i było w dokumencie kilka użyć słowa "assert" w normalnym angielskim znaczeniu, a poza tym było jedynie wyjaśnienie pewnych charakterystyk definicji makra assert.

> No i serio - o co teraz walczysz, tak konkretnie?

Z błędnym użyciem słowa "asercja".

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

#33012

> > W jakim sensie błędnie? W takim, że się ich używa?
> 
> W takim sensie, jak pisałem na początku.

No to od początku:

1. W kodzie krytycznym nie używa się asercji (w takim sensie, w jakim do tego pojęcia dobrnęliśmy od początku dyskusji[*]), bo
2. w przetestowanym kodzie tworzą dead-code, którego się unika z innych powodów.
3. Przesłanki do tego stwierdzenia widać też w dwóch najpoważniejszych standardach kodowania dla tej branży, które w ogóle nie zajmują się tematem asercji.

[*] Co ja interpretuję jako popularne użycie makra assert. Po ponownej lekturze linka z początku stwierdzam, że nie musiało chodzić o to makro, autorowi mogło chodzić też o inny mechanizm, bo wspominał o wracaniu do wołającej funkcji.

Nie pokałeś niczego, co by zaprzeczało tym stwierdzeniom albo rzucało nową lub inną perspektywę. Zamiast tego przerzucamy się wrażeniami z lektury Słownika Języka Polskiego i innymi zlepkami nie na temat. Nic to nie wnosi do dyskusji o tym, jak się pisze systemy krytyczne.

> > Nie rozumiesz. Nie ma rzeczy poza moim procesem.
> 
> Jest bardzo dużo rzeczy poza Twoim procesem.

W branży krytycznej nie ma.

> Na przykład całe Twoje wcześniejsze doświadczenie.

No właśnie. Nie na temat.

> Raczej jest tak, że programista napisze relewantny komentarz, potem inny programista zrefaktoryzuje kod, ale zapomni o aktualizacji komentarza, i komentarz przestaje być relewantny.

Nie, nie zapomni. W szczególności, to, co nazwałeś "refaktoryzacją" to nie jest coś, co sobie robi "inny programista", bo ma akurat taką inspirację. W szczególności, jeśli komentarze wykorzystywane są w takim celu jak pokazałem (z analizą statyczną), to ewentualne błędy zostaną autmatycznie wykryte.

> ,,Czy możemy w swoich pracach korzystać z fragmentów cudzych utworów,

Nadal nie na temat.

> To podaj chociaż tytuły dokumentów.

Standard języka C, MISRA-C, AUTOSAR. Pisałem już.
I nawet jeśli na siłę wyłuskasz z nich jakieś użycia słowa "assertion" nie na temat, to będą one, no właśnie, nie na temat.

> > No i serio - o co teraz walczysz, tak konkretnie?
> 
> Z błędnym użyciem słowa "asercja".

Rozumiem. Ale mi się nie chce. Wolę dyskutować o programowaniu.

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

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

#33013

> No to spróbujmy pierwszy przykład:
> 
> /*@ ensures \result >= x && \result >= y; 
>     ensures \result == x || \result == y; 
> */ 
> int max (int x, int y) { return (x > y) ? x : y; } 
> 
> int max (int x, int y) {
>   int result = (x > y) ? x : y;
>   assert(result >= x && result >= y);
>   assert(result == x || result == y);
>   return result;
> }
> 
> Udało się.

Nie udało się, z czterech powodów.

Po pierwsze, asercje (nazwijmy je raczej warunkami weryfikacji) w tych przykładach są właściwością deklaracji funkcji a nie jej ciała. Oznacza to, że są użyteczne zarówno przy weryfikacji ciała funkcji jak i przy weryfikacji kodu wołającego. Twoje asserty w ciele pełnią tylko tą pierwszą rolę, co je bardzo ogranicza.

Po drugie, warunki w komentarzach, gdzie są analizowane przez zewnętrzne narzędzie, nie podlegają ograniczeniom języka C i mogą korzystać nie tylko z szerszej składni, ale w ogóle z innego paradygmatu.

Po trzecie, na tym *pierwszym* przykładzie kończą się Twoje możliwości w tym zakresie. Niezbyt imponująco. Dalsze przykłady są ciekawsze (co nawiązuje do poprzedniego punktu).

Po czwarte wreszcie, Twoja wersja ma dead code. Mam nadzieję, że to nie wymaga ponownego wyjaśnienia.

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

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

#33023

On Sunday, September 8, 2019 at 10:17:20 PM UTC+2, Maciej Sobczak wrote:
> > No to spróbujmy pierwszy przykład:
> > 
> > /*@ ensures \result >= x && \result >= y; 
> >     ensures \result == x || \result == y; 
> > */ 
> > int max (int x, int y) { return (x > y) ? x : y; } 
> > 
> > int max (int x, int y) {
> >   int result = (x > y) ? x : y;
> >   assert(result >= x && result >= y);
> >   assert(result == x || result == y);
> >   return result;
> > }
> > 
> > Udało się.
> 
> Nie udało się, z czterech powodów.
> 
> Po pierwsze, asercje (nazwijmy je raczej warunkami weryfikacji) 

Dlaczego warto wprowadzać takie rozróżnienie nazewnicze, dlaczego nie używać
określenia asercj a warunków weryfikacyjnych?

Pozdrawiam

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

#33024

> > Po pierwsze, asercje (nazwijmy je raczej warunkami weryfikacji) 
> 
> Dlaczego warto wprowadzać takie rozróżnienie nazewnicze, dlaczego nie używać
> określenia asercj a warunków weryfikacyjnych?

Bo określenie "asercja" ma zbyt wiele znaczeń i u niektórych generuje chęć dyskusji nie na temat. :-)

No i termin "verification condition" jest bardziej sexy, niż "assertion" i skupia uwagę na temacie poprawności. Wpisz w Googlu jedno i drugie i porównaj wyniki. Od razu widać, że "verification condition" jest bardziej na temat.
;-)

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

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

#33031

On Wednesday, September 11, 2019 at 9:21:07 AM UTC+2, Maciej Sobczak wrote:
> > > Po pierwsze, asercje (nazwijmy je raczej warunkami weryfikacji) 
> > 
> > Dlaczego warto wprowadzać takie rozróżnienie nazewnicze, dlaczego nie używać
> > określenia asercj a warunków weryfikacyjnych?
> 
> Bo określenie "asercja" ma zbyt wiele znaczeń i u niektórych generuje chęć dyskusji nie na temat. :-)
> 
> No i termin "verification condition" jest bardziej sexy, niż "assertion" i skupia uwagę na temacie poprawności. Wpisz w Googlu jedno i drugie i porównaj wyniki. Od razu widać, że "verification condition" jest bardziej na temat.
> ;-)

A konkretnie, co jest na temat a co nie jest i na jaki? Nie wiem co to
jest "verification condition". Verification condition to te adnotacje, a
asercje to te marka/funkcje?

Pozdrawiam

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

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

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

csiph-web