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.
Możesz mieć rację, ale nie będę używał goto, bo tak (tu tupnięcie nogą) :) P.G.
Fatalny styl programowania ówczesnych początkujących programistów.
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.
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
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. :-)
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. :-)
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.
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" ...
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. :-)
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.
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 :)
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?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.