do {…} while (false)

Patrzyłem na jakiś kod przez osobę i zauważyłem, że wydaje się mieć wzorzec w swoich funkcjach:

<return-type> function(<params>)
{
 <initialization>

 do
 {
   <main code for function>
 }
 while(false);

 <tidy-up & return>
}

Nie jest zły , bardziej osobliwy (rzeczywisty kod jest dość schludny i nie jest zaskakujący). To nie jest coś, co widziałem wcześniej i zastanawiałem się, czy ktoś może wymyślić jakąś logikę za tym - być może tło w innym języku?

Możesz breakwyjść do{...}while(false).

Wiele osób zwraca uwagę, że często używa się go z przerwą jako niezręcznego sposobu pisania „goto”. To prawdopodobnie prawda, jeśli jest napisane bezpośrednio w funkcji.

W makrze OTOH do { something; } while (false)jest wygodnym sposobem na WYMUSZENIE średnika po wywołaniu makra, absolutnie żaden inny token nie jest dozwolony.

Inną możliwością jest to, że albo była tam kiedyś pętla, albo przewiduje się, że w przyszłości zostanie dodana iteracja (np. W programowaniu sterowanym testami iteracja nie była potrzebna, aby przejść testy, ale logicznie rzecz biorąc, pętla miałaby sens, gdyby funkcja musiała być nieco bardziej ogólna niż obecnie wymagana)

Przerwa jako goto jest prawdopodobnie odpowiedzią, ale przedstawię jeszcze jeden pomysł.

Może chciał mieć zmienne zdefiniowane lokalnie i użył tej konstrukcji, aby uzyskać nowy zakres.

Pamiętaj, że chociaż najnowsze C ++ pozwala na wszystko {...}, nie zawsze tak było.

Widziałem, że jest to użyteczny wzorzec, gdy istnieje wiele potencjalnych punktów wyjścia dla funkcji, ale ten sam kod czyszczenia jest zawsze wymagany, niezależnie od sposobu zakończenia funkcji.

Może to uczynić męczące drzewo jeśli / inaczej-jeśli o wiele łatwiejsze do odczytania, po prostu zmuszając się do łamania za każdym razem, gdy zostanie osiągnięty punkt wyjścia, a reszta logiki jest później wbudowana.

Ten wzorzec jest również przydatny w językach, które nie mają instrukcji goto. Być może właśnie tam pierwotny programista nauczył się wzoru.

Widziałem taki kod, więc możesz go używać breakjako swego gotorodzaju.

To jest po prostu wypaczenie, whileaby uzyskać sematykę programu goto tidy-upbez użycia słowa goto.

Jest to zła forma, ponieważ podczas korzystania z innych pętle wewnątrz zewnętrznej stają się dwuznaczne dla czytelnika. „Czy to ma doprowadzić do wyjścia? Czy ma to na celu jedynie wyrwanie się z wewnętrznej pętli?”whilebreaks

Myślę, że wygodniej jest pisać breakzamiast pisać goto end. Nie musisz nawet wymyślać nazwy dla etykiety, która wyjaśnia zamiar: nie chcesz przeskakiwać do etykiety o określonej nazwie. Chcesz się stąd wydostać.

Istnieje również szansa, że ​​i tak będziesz potrzebować aparatu ortodontycznego. Więc to jest do{...}while(false);wersja:

do {
   // code
   if (condition) break; // or continue
   // more code
} while(false);

I tak musiałbyś to wyrazić, gdybyś chciał użyć goto:

{
   // code
   if (condition) goto end;
   // more code
}
end:

Myślę, że znaczenie pierwszej wersji jest znacznie łatwiejsze do zrozumienia. Jest też łatwiejsze do pisania, łatwiejsze do rozszerzenia, łatwiejsze do przetłumaczenia na język, który nie obsługuje gotoitp.

Najczęściej wspominanym problemem związanym z używaniem breakjest to, że jest źle zamaskowany goto. Ale w rzeczywistości breakjest bardziej podobny do return: Obie instrukcje wyskakują z bloku kodu, który jest prawie uporządkowany w porównaniu z goto. Niemniej jednak obie instrukcje dopuszczają wiele punktów wyjścia w bloku kodu, co czasami może być mylące. W końcu starałbym się znaleźć jak najbardziej jasne rozwiązanie, niezależnie od tego, co jest w konkretnej sytuacji.

Ta sztuczka jest używana przez programistów, którzy są zbyt nieśmiali, aby używać jawnego gotokodu w swoim kodzie. Autor powyższego kodu chciał mieć możliwość bezpośredniego przeskoczenia do punktu „czyszczenie i powrót” ze środka kodu. Ale nie chcieli używać etykiety i jednoznacznie goto. Zamiast tego mogą użyć breakwewnątrz ciała powyższego „fałszywego” cyklu, aby osiągnąć ten sam efekt.

To bardzo powszechna praktyka. W C . Staram się o tym myśleć tak, jakbyś chciał się okłamywać w sposób „nie używam goto”. Myśląc o tym, nie byłoby nic złego w gotoużywaniu podobnie. W rzeczywistości zmniejszyłoby to również poziom wcięć.

Mimo to zauważyłem, że bardzo często te do..whilepętle rosną. A potem dostają ifs i elses do środka, przez co kod w rzeczywistości nie jest zbyt czytelny, nie mówiąc już o testowaniu.

Ci do..whilesą zazwyczaj przeznaczone zrobić Clean-up . Jak najbardziej, wolałbym użyć RAII i wrócić wcześniej z krótkiej funkcji. Z drugiej strony, C nie zapewnia tak wielu udogodnień, jak C ++ , co stanowi do..whilejedno z najlepszych podejść do czyszczenia.

Wygląda jak programista w C. W C ++ zmienne automatyczne mają destruktory, których używasz do czyszczenia, więc nie powinno być potrzeby ich porządkowania przed powrotem. W C nie miałeś tego idiomu RAII , więc jeśli masz wspólny kod czyszczący, możesz gotogo albo użyć pętli jednorazowej, jak powyżej.

Jego główną wadą w porównaniu z idiomem C ++ jest to, że nie uporządkuje, jeśli w treści zostanie zgłoszony wyjątek. C nie ma wyjątków, więc nie był to problem, ale sprawia, że ​​jest to zły nawyk w C ++.

Kilka wyjaśnień. Pierwsza jest ogólna, druga jest specyficzna dla makr preprocesora C z parametrami:

Kontrola przepływu

Widziałem to w zwykłym kodzie C. Zasadniczo jest to bezpieczniejsza wersja goto, ponieważ możesz się z niej wyrwać, a cała pamięć zostanie poprawnie wyczyszczona.

Dlaczego coś takiego jak gotobyłoby dobre? Cóż, jeśli masz kod, w którym prawie każda linia może zwrócić błąd, ale musisz zareagować na wszystkie z nich w ten sam sposób (np. Przekazując błąd dzwoniącemu po wyczyszczeniu), zwykle łatwiej jest uniknąć if( error ) { /* cleanup and error string generation and return here */ }as pozwala uniknąć powielania kodu oczyszczającego.

Jednak w C ++ masz wyjątki + RAII dokładnie w tym celu, więc uznałbym to za zły styl kodowania.

Sprawdzanie średników

Jeśli zapomnisz średnika po wywołaniu makra podobnego do funkcji, argumenty mogą skurczyć się w niepożądany sposób i skompilować się do prawidłowej składni. Wyobraź sobie makro

#define PRINT_IF_DEBUGMODE_ON(msg) if( gDebugModeOn ) printf("foo");

To jest przypadkowo nazwane jako

if( foo )
    PRINT_IF_DEBUGMODE_ON("Hullo\n")
else
    doSomethingElse();

„Inne” zostanie uznane za powiązane z elementem gDebugModeOn, więc kiedy foojest false, nastąpi dokładna odwrotność tego, co było zamierzone.

Zapewnienie zakresu dla zmiennych tymczasowych.

Ponieważ do / while ma nawiasy klamrowe, zmienne tymczasowe mają jasno określony zakres, przed którym nie mogą uciec.

Unikanie ostrzeżeń „prawdopodobnie niechcianych średników”

Niektóre makra są aktywowane tylko w kompilacjach do debugowania. Definiujesz je tak:

#if DEBUG
#define DBG_PRINT_NUM(n) printf("%d\n",n);
#else
#define DBG_PRINT_NUM(n) 
#endif

Teraz, jeśli użyjesz tego w kompilacji wydania wewnątrz warunku, kompiluje się do

if( foo )
    ;

Wielu kompilatorów uważa to za to samo, co

if( foo );

Które często jest napisane przypadkowo. Więc dostajesz ostrzeżenie. Do {} while (false) ukrywa to przed kompilatorem i jest przez niego akceptowane jako wskazanie, że naprawdę nie chcesz tutaj nic robić.

Unikanie przechwytywania linii przez warunkowe

Makro z poprzedniego przykładu:

if( foo )
    DBG_PRINT_NUM(42)
doSomething();

Teraz, w kompilacji do debugowania, ponieważ zwykle dodawaliśmy również średnik, kompiluje się to dobrze. Jednak w kompilacji wydania zmienia się to nagle w:

if( foo )

doSomething();

Lub wyraźniej sformatowany

if( foo )
    doSomething();

Co wcale nie jest tym, co było zamierzone. Dodanie do {...} while (false) wokół makra zamienia brakujący średnik w błąd kompilacji.

Co to oznacza dla PO?

Ogólnie rzecz biorąc, chcesz używać wyjątków w C ++ do obsługi błędów i szablonów zamiast makr. Jednak w bardzo rzadkich przypadkach, gdy nadal potrzebujesz makr (np. Podczas generowania nazw klas za pomocą wklejania tokenów) lub jesteś ograniczony do zwykłego C, jest to przydatny wzorzec.

Może jest breakużywany w celu przerwania wykonywania dalszego kodu w dowolnym momencie:

do {
    if (!condition1) break;
    some_code;
    if (!condition2) break;
    some_further_code;
    // …
} while(false);

Myślę, że ma to na celu użycie breaklub continueoświadczenia. Jakiś rodzaj logiki „goto”.

To proste: najwyraźniej możesz wyskoczyć z fałszywej pętli w dowolnym momencie, używając breakinstrukcji. Ponadto doblok jest oddzielnym zakresem (który można również osiągnąć { ... }tylko za pomocą ).

W takiej sytuacji lepszym pomysłem może być użycie RAII (obiekty automatycznie niszczą się poprawnie po zakończeniu funkcji). Inną podobną konstrukcją jest użycie goto- tak, wiem, że to zło , ale można go użyć do posiadania wspólnego kodu czyszczącego, takiego jak:

<return-type> function(<params>)
{
 <initialization>

 <main code for function using "goto error;" if something goes wrong>

 <tidy-up in success case & return>

 error:

 <commmon tidy-up actions for error case & return error code or throw exception>
}

(Na marginesie: konstrukcja do-while-false jest używana w Lua, aby znaleźć brakującą continueinstrukcję).

Wielu respondentów podało powód do{(...)break;}while(false). Chciałbym uzupełnić ten obraz o kolejny przykład z życia wzięty.

W poniższym kodzie musiałem ustawić moduł wyliczający operationna podstawie adresu wskazywanego przez datawskaźnik. Ponieważ przypadek przełącznika może być używany tylko na typach skalarnych, najpierw zrobiłem to nieefektywnie w ten sposób

if (data == &array[o1])
    operation = O1;
else if (data == &array[o2])
    operation = O2;
else if (data == &array[on])
    operation = ON;

Log("operation:",operation);

Ale ponieważ Log () i reszta kodu powtarza się dla dowolnej wybranej wartości operacji, zastanawiałem się, jak pominąć resztę porównań, gdy adres został już odkryty. I tu się do{(...)break;}while(false)przydaje.

do {
    if (data == &array[o1]) {
        operation = O1;
        break;
    }
    if (data == &array[o2]) {
        operation = O2;
        break;
    }
    if (data == &array[on]) {
        operation = ON;
        break;
    }
} while (false);

Log("operation:",operation);

Można się zastanawiać, dlaczego nie mógł zrobić tego samego breakw ifoświadczeniu, takim jak:

if (data == &array[o1])
{
    operation = O1;
    break;
}
else if (...)

breakoddziałuje wyłącznie z najbliższą otaczającą pętlą lub przełącznikiem, czy to typu a for, whileczy do .. whiletypu, więc niestety to nie zadziała.

Ile lat miał autor?

Pytam, ponieważ pod koniec lat 80-tych natknąłem się kiedyś na kod Fortran działający w czasie rzeczywistym, który to zrobił. Okazuje się, że to naprawdę dobry sposób na symulowanie wątków w systemie operacyjnym, który ich nie ma. Po prostu umieszczasz cały program (swój program planujący) w pętli i wywołujesz swoje „procedury wątku” jeden po drugim. Same procedury wątku są pętlami, które wykonują iterację aż do wystąpienia jednego z wielu warunków (często jeden jest określoną ilością Jest to „wielozadaniowość kooperacyjna”, w której poszczególne wątki od czasu do czasu rezygnują z procesora, aby inne nie zostały zagłodzone. Możesz zagnieżdżać wywołania podprogramu zapętlonego, aby symulować priorytet wątku Zespoły.

Oprócz wspomnianych już przykładów „goto”, idiom do ... while (0) jest czasami używany w definicji makra, aby zapewnić nawiasy w definicji, a kompilator nadal pracuje z dodaniem średnika na końcu wywołanie makro.

http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/52f670f1292f30a4?tvc=2&q=while+(0)

Zgadzam się z większością plakatów o użyciu jako słabo zamaskowanej goto. Wspomniano również o makrach jako potencjalnej motywacji do pisania kodu w stylu.

Widziałem również tę konstrukcję używaną w mieszanych środowiskach C / C ++ jako wyjątek dla biednych. Polecenie „do {} while (false)” z „break” może być użyte do przeskoczenia do końca bloku kodu, gdyby w pętli wystąpiło coś, co normalnie gwarantowałoby wyjątek.

Skorzystałem również z tej konstrukcji używanej w sklepach, w których obowiązuje ideologia „pojedynczego zwrotu na funkcję”. Ponownie, jest to zamiast wyraźnego „goto” - ale motywacją jest unikanie wielu punktów powrotu, a nie „pomijanie” kodu i kontynuowanie rzeczywistego wykonywania w ramach tej funkcji.

Pracuję z Adobe InDesign SDK, a przykłady InDesign SDK mają prawie każdą funkcję napisaną w ten sposób. Wynika to z faktu, że funkcje są zwykle bardzo długie. Gdzie musisz zrobić QueryInterface (...), aby uzyskać cokolwiek z modelu obiektów aplikacji. Tak więc zwykle po każdym interfejsie QueryInterface występuje błąd, który się ifnie udał, przerwa.

Wielu już stwierdziło podobieństwo między tą konstrukcją a a gotoi wyraziło preferencje dla goto. Być może przeszłość tej osoby obejmowała środowisko, w którym goto było surowo zabronione przez wytyczne dotyczące kodowania?

Innym powodem, dla którego przychodzi mi do głowy, jest to, że ozdabia nawiasy klamrowe, podczas gdy uważam, że nowszy standard C ++ nie jest w porządku (ISO C ich nie lubi). W przeciwnym razie, aby wyciszyć analizator statyczny, taki jak kłaczki.

Nie jestem pewien, dlaczego chcesz je mieć, może zakres zmienny lub korzyść z debugera.

Zobacz Trivial Do While loop i Braces are Good from C2.

Aby wyjaśnić moją terminologię (która moim zdaniem jest zgodna ze standardowym użyciem):

Nagie szelki :

init();
...
{
c = NULL;
mkwidget(&c);
finishwidget(&c);
}
shutdown();

Puste szelki (NOP):

{}

na przykład

while (1)
   {}  /* Do nothing, endless loop */

Blok :

if (finished)
{
     closewindows(&windows);
     freememory(&cache);
}

który stanie się

if (finished)
     closewindows(&windows);
freememory(&cache);

jeśli nawiasy zostaną usunięte, zmieniając w ten sposób przepływ wykonywania, a nie tylko zakres zmiennych lokalnych. Zatem nie jest „wolnostojący” lub „nagi”.

Nagie nawiasy klamrowe lub blok mogą być używane do oznaczania dowolnej sekcji kodu, która może być potencjalną funkcją (wbudowaną), którą chcesz oznaczyć, ale nie w tym czasie refaktoryzacji.

To wymyślony sposób na emulację a, GOTOponieważ te dwa są praktycznie identyczne:

// NOTE: This is discouraged!
do {
    if (someCondition) break;
    // some code be here
} while (false);
// more code be here

i:

// NOTE: This is discouraged, too!
if (someCondition) goto marker;
// some code be here
marker:
// more code be here

Z drugiej strony, obie te rzeczy naprawdę powinny być zrobione za pomocą ifs:

if (!someCondition) {
    // some code be here
}
// more code be here

Chociaż zagnieżdżanie może stać się nieco brzydkie, jeśli po prostu zamienisz długi ciąg znaków forward GOTOw zagnieżdżone ifs. Prawdziwą odpowiedzią jest jednak właściwa refaktoryzacja, a nie naśladowanie archaicznych konstrukcji językowych.

Jeśli desperacko próbowałeś transliterować algorytm zawierający GOTOs, prawdopodobnie mógłbyś to zrobić za pomocą tego idiomu. Z pewnością jest to niestandardowe i dobre wskazanie, że nie trzymasz się ściśle oczekiwanych idiomów języka.

Nie znam żadnego języka podobnego do języka C, w którym funkcja do / while jest idiomatycznym rozwiązaniem na wszystko.

Prawdopodobnie mógłbyś przekształcić cały bałagan w coś bardziej sensownego, aby uczynić go bardziej idiomatycznym i znacznie bardziej czytelnym.

Niektórzy programiści wolą mieć tylko jedno wyjście / powrót ze swoich funkcji. Użycie atrapy do {....} while (false); pozwala na „wyrwanie się” z atrapy pętli po zakończeniu i nadal mieć pojedynczy powrót.

Jestem programistą java, więc mój przykład byłby podobny

import java.util.Arrays;
import java.util.List;
import java.util.Set;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class p45
{
    static List<String> cakeNames = Arrays.asList("schwarzwald torte", "princess", "icecream");
    static Set<Integer> forbidden = Stream.of(0, 2).collect(Collectors.toSet());

    public static  void main(String[] argv)
    {
        for (int i = 0; i < 4; i++)
        {
            System.out.println(String.format("cake(%d)=\"%s\"", i, describeCake(i)));
        }
    }


    static String describeCake(int typeOfCake)
    {
        String result = "unknown";
        do {
            // ensure type of cake is valid
            if (typeOfCake < 0 || typeOfCake >= cakeNames.size()) break;

            if (forbidden.contains(typeOfCake)) {
                result = "not for you!!";
                break;
            }

            result = cakeNames.get(typeOfCake);
        } while (false);
        return result;
    }
}

W takich przypadkach używam

switch(true) {
   case condution1:
      ...
      break;
   case condution2:
      ...
      break;
}

To jest zabawne. Prawdopodobnie w pętli są przerwy, jak powiedzieli inni. Zrobiłbym to w ten sposób:

while(true)
{
   <main code for function>
   break; // at the end.
}