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.