On 2017-01-27 22:55, slawek wrote:
>> C++ w programie na linuxa.
> Czyli języku bez GC i bez maszyny wirtualnej. W którym błąd "null
> pointer" wywołuje panikę programistów.

Nie bądź zdziwiony. Tutaj jest o tym mowa. Zaryzykuje również że jeśli
mowa o Linuxie to 95% softu takie jest. Zastanawiające że próbujesz
zachowac twarz uciekając w jezyki z GC skoro była jasno mowa o Linuxie.
Za chwile się okaże że wzrocowa jest maszyna wirtualna javy bo przecież
wątek jest o Javie. A jest, nie?

> Owszem. Tyle że - jak już misiu nauczysz się jak wygląda obsługa
> wyjątków w Javie/C#/Delphi a nawet C++ - wytegolenie się połowy programu
> nie oznacza że program musi przestać działać.

Wyjątki w C++ znam w szczegółach, czesto debuguje cieżkie przypadki i
bywa że robie to na poziomie asm. Jako misio nie zauważyłem aby C++
łapał try catch wyjątki dereferencji nulla. Być może w paralernym
wszechświecie w którym istniejesz. Tak, są implementacje C++ które
pozwalają łapać wyjątki systemowe przez niestandardowe rozszerzenia. Nie
mają za dużego związku z C++ i nie powodują że algorytm z automatu da
się popchnąc dalej. W zasadzie są dośc katastrofalne w skutkach ponieważ
zazwyczaj byle jak lub zupełnie nie zwijają stosu zostawiając stos w
stanie niestabilnym. RAII idzie do piachu.

> Zwłaszcza jeżeli jest
> event driven. Dla przykładu: null pointer bo nie ma drukarki, ale
> przecież nie musisz drukować jak nie ma drukarki. Ważne aby dało się
> dane zapisać. I gdy już podłączysz drukarkę dostaniesz drugą szansę...
> śliczny pointer nie null. I to bez przerwy w działaniu całego programu.

Fascynujące. Opisujesz wysokopoziomowy projekt jakiegos mechanizmu i
jednoczesnie zarzucasz mi brak rozumienia co to jest null pointer
dereference? No weź przestań. Chyba nie chcesz tego mechanizmu
implementowac przechwytując wyjatki SIGSERV? No no, szacun. To jakiś
nowy wzorzec projektowy, null pointer oriented programming może by go
nazwać?

>> Oczywiście że się kończą. Aby to sprawdzić możesz poświęcić 4
> minuty.
> A to porozmawiaj o tym z moim programem, który przez dwa dni liczył
> sobie na inf'ach i nan'ach. Nie kończył się... Ale może to wina
> Fortranu? Bo procesor całkiem zwyczajny I7.

Dzielenie przez zero powoduje wyjatek sprzetowy. Używanie do obliczeń
Nan *może* powodować wyjątek jesli chcesz, albo nie. To cecha wielu FPU.
I mozna tym sterowac z poziomu kodu. Mozna tez sobie dodać ifa w kodzie
wynikowymj przy kompilacji a przed dzieleniem i samodzielnie w runtime
wygenerować exception jak chcesz a potem mówić że dzielenie przez zero
nie zatrzymuje aplikacji.

Tu masz wyjasnione:

http://stackoverflow.com/questions/18118408/what-is-
difference-between-quiet-nan-and-signaling-nan

Nie ma się co dziwic że istnieją *jakieś* niepopularne języki
programowania gdzie bugi są suppresowane na poziomie kompilatora i
runtime używając spacjalnego bitu w liczbie nan. A może wystarczy flaga
do kompilatora aby to zachowanie zmienić.

>> char *a = 0;
>> chat x = *a;
>
> Rozumiem że miało być char?
>
> W czym problem? Pierwsza linijka to niechlujstwo, ale w C++ może
> przejść.

Nie, to dzień jak codzień. Inicjowanie pointera na null jest bezpieczne.
I częste.

> Druga linijka powinna wywołać wyjątek.

Moze. Nie musi. To jest UB. Może rownie dobrze odkręcić kran w piwnicy
albo zajodłować.

Wiele OSów aby silnie zdefiniować to UB stawia pułapkę sprzętową na tym
adresie (0) i zabija aplikację. Natychmiast o ile nie przechwycisz
*specjalnego* wyjątku systemowego. Tylko że w złozonym programie po jego
przechwyceniu niewiele da się zrobić poza poskładaniem tego co się da
*ewentualnie* poskładać i wyjściem z racji faktu że ten wyjątek
systemowy ma głeboko w d... RAII.

> I jak ten wyjątek
> olejesz, to faktycznie program zwyczajowo się kończy. Ale cały myk że
> możesz nie olewać, tylko zrobić coś mądrego.

Co?

> No wiem że akurat tobie
> będzie trudno zrobić coś mądrego.

Więc pokaz jak zrobić coś madrego w tej sytuacji w C++. Jeśli nie znasz
skladni możesz to opisać słowami. W C++, prosze.

Skoro postanowiłes się kompromitować to ciągnijmy to dalej, niechaj
będzie troche pośmiewiska.