[karol221-10]

#cpp #programowanie #naukaprogramowania #kompikownia
Witajcie :) Nie było mnie tu przez 2 tyg :( Niestety studia zabierają nieco czasu. Dzisiaj chciałbym wam pokazać analizę tzw. "undefined behavior" - niezdefiniowanego zachowania. Co to jest, skąd to się bierze i do czego prowadzi? O tym przeczytacie w moim najnowszym wpisie:
https://www.kompikownia.pl/index.php/2019/03/27/czym-jest-undefined-behavior-w-c-c/
Zapraszam :)

[CppPolska]

@karol221-10: W sumie dałem plusa (bo jest #cpp), ale z drugiej strony konstruktywna krytyka:

Używaj asercji. To bardzo dobry wynalazek. Sprawia, że możesz być spokojny o to, że twój program wykonuje się prawidłowo.

https://en.cppreference.com/w/cpp/error/assert

If NDEBUG is defined as a macro name at the point in the source code where is included, then assert does nothing.

Do tego, gdyby nawet assert działał w kodzie produkcyjnym, to nie polecam. Chyba nie

[CppPolska]

@karol221-10:

Musimy nauczyć się z nim żyć, a nawet próbować wykorzystywać undefined behavior na własną korzyść

(╯°□°）╯︵ ┻━┻

Do UB nigdy nie powinno dojść, ponieważ NIGDY nie wiesz, co wtedy się wydarzy. Dodatkowo, kompilatory wykorzystują UB jako dodatkową furtkę do optymalizacji, ponieważ zakładają, że do UB nigdy nie dochodzi.

[karol221-10]

@CppPolska: Dzięki za opinię :) Chodziło mi oczywiście o wykorzystanie asercji podczas debugowania kodu. Mogło się do wydawać niejasne podczas czytania, dlatego dodałem adnotację w nawiasie.

[karol221-10]

@CppPolska: Z tą myślą chodziło mi właśnie o to co napisałeś :) A mianowicie o sztuczki optymalizacyjne kompilatora.

[CppPolska]

@karol221-10: Zawarłbym konkretniej to, o co Ci chodzi z optymalizacjami kompilatora. Bo inaczej ludzie będą korzystali z UB, dopuszczając do nich.