W dniu 2017-10-24 o 13:42, Piotr Wyderski pisze:
>
> A mnie się zdarza stosunkowo często, choć przypadki użycia są jedynie dwa:
>
> 1. Opuszczanie wielokrotnie zagnieżdżonych pętli.
> 2. Przekazywanie sterowania do wspólnego kodu obsługi błędu dla danej
> sytuacji:
>
> if (dobrze) {
>
>     // to dobrze
> } else {
>
> lbl_zle:
>
>     // bardzo zle
> }
>
> if (albo_jednak_zle) {
>
>     goto lbl_zle;
> }

Taka konstrukcja z cofaniem się w kodzie jest dla mnie trudna.
Nie rozumiem czy zakładasz, że albo_jednak_zle może być true po
wykonaniu bloku dobrze, czy else.
Jak po else to znaczyło by, że kod //bardzo zle nie gwarantuje, że
albo_jednak_zle będzie false - czyli może się zapętlić.
A jak po dobrze to by znaczyło, że warunek dobrze nie jest 100% pewny.

Kiedyś dawno błędy zawsze obsługiwałem tak, że wszystkie funkcje
zwracały int i każda wyższa reagowała na to, co zwraca niższa jak
umiała, a jak nie to przekazywała błąd wyżej (czasem nadając mu już inny
numer). Nigdy nie obsługiwałem błędów danej funkcji w niej samej.

Od jakiegoś czasu staram się używać try{throw;}catch bo nie trzeba
myśleć o przekazywaniu wyżej błędów przychodzących z dołu.

> Dokładnie o to chodzi. Goto potrafi znacznie *podnieść* czytelność,

Możesz mieć rację, ale nie będę używał goto, bo tak (tu tupnięcie nogą) :)
P.G.

do góry

Piotr Gałka wrote:

>> Pomysl lepiej ile razy kombinowales, gdy jedno goto zalatwiloby sprawe,
>
> Czasem kombinowałem, ale na prawdę nie pamiętając w ogóle o istnieniu
> goto nigdy nie miałem myśli "jedno goto załatwiloby sprawę" dlatego nie
> mam pojęcia czy tak było w tych przypadkach gdy kombinowałem.

Piotrze, powody niechęci do goto były dwa:

1. Fatalny styl programowania ówczesnych początkujących programistów.

2. Niedostateczny rozwój metod translacji w zakresie analizy i
optymalizacji tzw. nieredukowalnych grafów przepływu, do których
powstania *może* doprowadzić goto, a konstrukcje "strukturalne"
w rodzaju break i continue nie. Jestem osobiście przekonany, że
o to właśnie tak naprawdę poszło, a mitologię dorobiono później.
No ale lata 60. się jakiś czas temu skończyły i problemu grafów
nieredukowalnych już nie ma, kompilatory robią transformacje,
które się nie śniły pionierom... No ale trendy narzuca ten, kto
pisze podręczniki... :-)

> Jak dopada mnie taki przypadek to robię podfunkcję z której w wielu
> miejscach wychodzę przez return - w sumie to podobne do goto i możliwe
> że też jest 'be'.

A jak masz kaskadowe returny? Funkcja bardziej niż z siebie nie wróci
i się zaczynają piętrowe ifki do obsługi takich sytuacji. Dobrze użyte
goto jest dobre, ale to konstrukcja dla ekspertów. Tylko jest różnica
między zakazywaniem a rekomendowaniem nieużywania.

Pozdrawiam, Piotr

do góry

W dniu 2017-10-24 o 13:52, J.F. pisze:
>
> W assemblerze mi sie nie mylilo :-)
>
Nigdy nie pisałem w assemblerze tylko raz pisałem assembler :)
P.G.

do góry

W dniu 2017-10-24 o 14:07, Piotr Wyderski pisze:
>
> A jak masz kaskadowe returny? Funkcja bardziej niż z siebie nie wróci
> i się zaczynają piętrowe ifki do obsługi takich sytuacji.

Na szczęście throw wróci nie tylko z siebie :) i jeszcze po drodze
wszystko posprząta wywołując odpowiednie destruktory.
P.G.

do góry

Piotr Gałka wrote:

> Taka konstrukcja z cofaniem się w kodzie jest dla mnie trudna.

No to jej nie używaj, to nie jest ani przymusowe, ani nawet częste.
Ja się tylko sprzeciwiam wieszaniu psów na tym niezwykle użytecznym
narzędziu. Kolega ujął to w charakterystyczny dla siebie sposób:
"jak się umie, to można nawet pić aceton".

> Nie rozumiem czy zakładasz, że albo_jednak_zle może być true po
> wykonaniu bloku dobrze, czy else.

To jest szkic pewnego ogólnego sposobu programowania: ścieżka
najbardziej prawdopodobna powinna być fizycznie najprostsza,
liniowa, bo to podnosi czytelność programu. Nawet kosztem ścieżek
obsługi błędów.

> Jak po else to znaczyło by, że kod //bardzo zle nie gwarantuje, że
> albo_jednak_zle będzie false - czyli może się zapętlić.

Potencjalnie tak, milczące założenie to niekontynuowalność
ścieżki błędnej: rzucenie wyjątku, ustawienie errno, return,
jak kto ma w coding standard ustalone.

> A jak po dobrze to by znaczyło, że warunek dobrze nie jest 100% pewny.

No bo często nie jest. Stopniowo sobie odsiewasz możliwości na
ścieżce głównej. Jeśli warunek jest fałszywy, to stan na 100% nie
jest poprawny, jeśli jest prawdziwy, to *być może* jest poprawny.
Trochę jak w filtrach Bluma. Goto pozwala Ci niezwielokratniać
ścieżek obsługi błędu (zakładając, że taka unifikacja ma sens
logiczny i rozmawiamy tylko o sprawach organizacji strukturalnej).

> Kiedyś dawno błędy zawsze obsługiwałem tak, że wszystkie funkcje
> zwracały int i każda wyższa reagowała na to, co zwraca niższa jak
> umiała, a jak nie to przekazywała błąd wyżej (czasem nadając mu już
> inny numer). Nigdy nie obsługiwałem błędów danej funkcji w niej samej.

To działa dopóki realizujesz to konsekwentnie. Wystarczy
w jednym miejscu zapomnieć i obsługa błędów zdycha. Druga
sprawa to ta obsługa wyżej, to złożona sprawa. Funkcja
wyższego poziomu często nie ma kontekstu do właściwego
zinterpretowania błędu i popadamy w drugą skrajność:
użytkownik dostaje w twarz komunikatem, że pod adresem
0x1234 znaleziono wartość 0x5678 i pomimo absolutnej
poprawności przekazanych mu informacji nie ma pojęcia,
co z tym zrobić. Drugi koniec spektrum wyznacza autentyczny
wpis do logu o treści "Coś jebło, aborting". Trzeba znaleźć
złoty środek. :-)

> Możesz mieć rację, ale nie będę używał goto, bo tak (tu tupnięcie
nogą) :)

W tym zakresie wykazuję się pełnym ekumenizmem. :-)
Rób *porządnie*, a nie skupiaj się na narzędziach do osiągnięcia tego celu.

> Od jakiegoś czasu staram się używać try{throw;}catch bo nie trzeba
> myśleć o przekazywaniu wyżej błędów przychodzących z dołu.

Niestety nie Ty jeden. Pilny lot do USA z dokładnie tego
powodu już ćwiczyliśmy, bo się produkcyjny system w środku
nocy zatrzymał i to niestety nie w warzywniaku. :-)

Pozdrawiam, Piotr

do góry

Piotr Gałka wrote:

> Na szczęście throw wróci nie tylko z siebie :)

Chyba, że na swej drodze spotka rycerza Kacz Trzy Kropy
i potem Pszemol nie ma telefonu. ;-)))

> i jeszcze po drodze wszystko posprząta wywołując odpowiednie destruktory.

Destruktory wywoła, ale liczenie, że posprząta, wymaga wulkanu
optymizmu. Niestety zwykle system przejdzie ze stanu "mniej-więcej
wiadomo, co się dzieje" do "kompletnie nie wiadomo, więc radośnie
działajmy dalej". Mało który zawodowy programista C++ potrafi pisać
kod bezpieczny ze względu na wyjątki (choć jest przekonany, że potrafi)
i różne Google pozakazywały używania wyjątków w swoim kodzie.

Pozdrawiam, Piotr

do góry

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:osnadg$lfn$...@n...news.atman.pl...
Piotr Gałka wrote:
>>> Pomysl lepiej ile razy kombinowales, gdy jedno goto zalatwiloby
>>> sprawe,
>> Czasem kombinowałem, ale na prawdę nie pamiętając w ogóle o
>> istnieniu
>> goto nigdy nie miałem myśli "jedno goto załatwiloby sprawę" dlatego
>> nie
>> mam pojęcia czy tak było w tych przypadkach gdy kombinowałem.

>Piotrze, powody niechęci do goto były dwa:
>1. Fatalny styl programowania ówczesnych początkujących programistów.

IMO - dzis bylby podobnie fatalny, tylko dzis od poczatku sie ich uczy
w "strukturalnym jezyku", nawet jesli to (Visual) Basic.

>2. Niedostateczny rozwój metod translacji w zakresie analizy i
>optymalizacji tzw. nieredukowalnych grafów przepływu, do których
>powstania *może* doprowadzić goto, a konstrukcje "strukturalne"
>w rodzaju break i continue nie. Jestem osobiście przekonany, że
>o to właśnie tak naprawdę poszło, a mitologię dorobiono później.

Cos w tym jest, bo istotnie optymalizacja moze byc trudna ... ale juz
IMP Fotran H bardzo dobrze optymalizowal, a na C i Pascala bylo
jeszcze za wczesniej.
Pascal ... tam sie chyba na optymalizatorze nie skupiano.

>No ale lata 60. się jakiś czas temu skończyły i problemu grafów
>nieredukowalnych już nie ma, kompilatory robią transformacje,
>które się nie śniły pionierom... No ale trendy narzuca ten, kto
>pisze podręczniki... :-)

> > Jak dopada mnie taki przypadek to robię podfunkcję z której w
> > wielu
> > miejscach wychodzę przez return - w sumie to podobne do goto i
> > możliwe
> > że też jest 'be'.
>A jak masz kaskadowe returny? Funkcja bardziej niż z siebie nie wróci
>i się zaczynają piętrowe ifki do obsługi takich sytuacji.

No, goto miedzy funkcjami nie dziala :-)

>Dobrze użyte
>goto jest dobre, ale to konstrukcja dla ekspertów. Tylko jest różnica
>między zakazywaniem a rekomendowaniem nieużywania.

Tylko zanim czlowiek ekspertem zostanie, to trzeba cwiczenia zaliczyc,
albo mlodszego programiste zaliczyc, i uslyszy sie "w tym programie
jest goto, to jest zly program, prosze to poprawic" ...

J.

do góry

J.F. wrote:

> Cos w tym jest, bo istotnie optymalizacja moze byc trudna ...

Starsze podręczniki o konstrukcji kompilatorów poświęcały
temu spory procent swojej objętości.

> No, goto miedzy funkcjami nie dziala :-)

Ale jeśli da się przenieść główny koszt wydajnościowy
do funkcji liściowej, co jest częste, to da się ją
"spłaszczyć" przy pomocy goto i względny koszt propagacji
błędów znacznie spadnie.

> Tylko zanim czlowiek ekspertem zostanie, to trzeba cwiczenia zaliczyc,
> albo mlodszego programiste zaliczyc, i uslyszy sie "w tym programie jest
> goto, to jest zly program, prosze to poprawic" ...

Zazwyczaj bez rzetelnego wyjaśnienia, dlaczego program jest zły.
Ja z kolei dwóch pracowników przekonałem do goto po prostu pokazując
im tak napisany program. Ale to byli znakomici programiści. :-)

Pozdrawiam, Piotr

do góry

W dniu 2017-10-24 o 11:58, Piotr Gałka pisze:
> W dniu 2017-10-24 o 11:22, Janusz pisze:
>
>>> Tak się zastanawiam do czego ona mogła by być przydatna i nie bardzo
>>> potrafię wymyślić jakiś przykład generujący realną taką potrzebę.
>> Znalazłby się, np wyjście z podwójnej pętli, breakiem wyjdziesz tyle że
>> pętlę wyżej gdzie musisz testować warunek dalszego wyjścia, jak widzisz
>> zaciemnia się kod i robi się to mało eleganckie.
>>
>
> Kiedyś przetestowałem break;break; i OIDP zadziałało dobrze, ale nie
> byłem pewien, czy to przypadek, czy cecha języka więc dołożyłem bool
> który służył tylko do tego aby zewnętrza pętla wiedziała, że wewnętrzna
> każe wyjść. Potem chyba zastąpiłem wewnętrzną przez osobną funkcję
> inline i wydaje mi się to lepszym/czytelniejszym rozwiązaniem niż goto.
Ale inline nic nie zmienia, to jest tylko sposób wywołania funkcji,
nadal masz zagnieżdżone pętle i potrzebę bezbolesnego wyjścia z tego
bagna.

> Kilka lat temu kupiłem sobie ostatnią książkę Stroustrupa o C++.
> Nie przebrnąłem przez całą. Utkwiło mi w pamięci, że według niego jak
> funkcja ma więcej jak 7 linijek to znaczy, że program jest źle napisany.
Wg mnie bzdura, rozdrabnianie funkcji a do tego dąży ta niby "zasada"
także zaciemnia program.

--
Pozdr
Janusz

do góry

W dniu 2017-10-24 o 17:36, Janusz pisze:
> Ale inline nic nie zmienia, to jest tylko sposób wywołania funkcji,
> nadal masz zagnieżdżone pętle i potrzebę bezbolesnego wyjścia z tego
> bagna.

Chodziło mi tylko o czytelność. Napisałem inline aby podkreślić, że da
się to zrobić bez pogarszania wydajności.

Zrozumienie co robi pętla:

for(;;)
{
jakies dzialania
if(wewn_petla())break;
inne dzialania
}

wydaje mi się łatwiejsze gdy między działaniami przed i po jest tylko
jedna linijka a nie ileś tam wewnętrznej pętli.

Oczywiście to rzecz względna i zależy od konkretnej sytuacji. Jak tę
wewnętrzną pętlę da się w jednej linijce zapisać:

bool flag=false;
for(;;){... ; if(..){flag=true;break;}}
if(flag)break;

to robienie z niej funkcji nie ma wielkiego sensu, ale jak ona ma z 10
linijek to już bym się zastanawiał, a przy 20 to chyba już bym się nie
zastanawiał.
P.G.

do góry