programowanie w C - bardzo ogólne pytanie o filozofi

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... :-)

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

W dniu 2017-10-24 o 13:52, J.F. pisze:

Nigdy nie pisałem w assemblerze tylko raz pisałem assembler :) P.G.

W dniu 2017-10-24 o 14:07, Piotr Wyderski pisze:

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

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

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.

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.

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

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

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.

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

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

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

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

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, goto miedzy funkcjami nie dziala :-)

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.

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

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.

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

W dniu 2017-10-24 o 11:58, Piotr Gałka 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.

Wg mnie bzdura, rozdrabnianie funkcji a do tego dąży ta niby "zasada" także zaciemnia program.

W dniu 2017-10-24 o 17:36, Janusz pisze:

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.

W dniu 2017-10-24 o 20:31, Piotr Gałka pisze:

Ok.

Piotr Gałka snipped-for-privacy@cutthismicromade.pl napisał(a):

Nieraz emuluje się w ten sposób w C wyjątki dostępne w C++, takie natychmiastowe wyjście z nawet mocno zagnieżdżonego kodu i przeskok do etykiety obsługującej wyjątek.

Ja tam myślę że jest odwrotnie - to C++ ze swoją całą "wyjątkowością" próbuje emulować niezastąpione GOTO, bo to ostatnie z dnia na dzień przestało być modne :)

Mateusz

C++ ma goto, więc niczego emulować nie musi.

Ono jest tak samo modne, jak kolonoskopia -- czasami trzeba...

Pozdrawiam, Piotr

A po wuja goto? Już w latach 70-tych wiedziano że nie ma sensu używać skoków. Nota bene, w pralkach bywają dwa mikrokontrolery. Jeden do ogólnej logiki, drugi do sterowania samym silnikiem.

Ale... pralka zasilana jest z 230V AC, jest woda, może urwać rękę, obciąć palce, albo zwyczajnie zalać sąsiadów itp. przy próbach i "debugowaniu". Czy nie lepiej zacząć od czegoś bezpieczniejszego, a jednocześnie bardziej innowacyjnego niż pralka?

Ogólnie, w czymkolwiek to się programuje jak w czymkolwiek. Znaczy siedzi się (lub stoi lub leży lub zwisa) i programuje.

Tyle że programowanie w C++ obiektowo a w Basic ZX Spektrum to zupełnie różne światy. Trochę tak jak chodzenie po linie i chodzenie po trawie.

Nigdy się nie przydaje. No może poza jednym: pozwala odsiać marnych programistów i kiepskie firmy. Oczywiście mowa o C, a nie Fortranie IV.

Jak ktoś zna tylko pętlę for, to używa break i - gdy sprawy się komplikują - goto.

Przeczytałem kilka książek Stroustrupa. Raczej łatwa lektura. Raczej mądry człowiek, mądrzejszy niż różne Mateuszki. Ale może ja się nie znam.

Miejsce BCB5 jest w muzeum, zresztą to kiepski kompilator był. Najśmieszniejsze: błędnie generowały kod dla goto.

A sprawdza się że standardem.