{…} while（false）を実行

私は個人がいくつかのコードを見ていて、彼が彼の機能にパターンを持っているように見えることに気づきました：

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

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

 <tidy-up & return>
}

それは悪くはなく、より奇妙です（実際のコードはかなりきちんとしていて驚くことではありません）。それは私が以前に見たものではなく、誰かがその背後にあるロジックについて考えることができるかどうか疑問に思いました-おそらく別の言語の背景？

あなたはbreak外にすることができdo{...}while(false)ます。

多くの人が、「goto」を書くのに厄介な方法として、breakと一緒に使用されることが多いと指摘しています。関数に直接記述されている場合は、おそらくそれが当てはまります。

マクロでは、OTOH do { something; } while (false)は、マクロの呼び出し後にセミコロンを強制する便利な方法です。絶対に他のトークンを続けることはできません。

もう1つの可能性は、ループがあったか、反復が将来追加されることが予想されることです（たとえば、テスト駆動開発では、テストに合格するために反復は必要ありませんでしたが、論理的にはループする場合に意味があります）関数は、現在必要なものよりもいくぶん一般的である必要がありました）

gotoとしての休憩はおそらく答えですが、私はもう1つのアイデアを提案します。

おそらく、彼はローカルに定義された変数を持ちたいと考え、この構成を使用して新しいスコープを取得しました。

最近のC ++では{...}どこでも可能ですが、これが常に当てはまるとは限りません。

これは、関数の潜在的な出口点が多数ある場合に有用なパターンとして使用されることを確認しましたが、関数の終了方法に関係なく、常に同じクリーンアップコードが必要です。

終了ポイントに到達するたびにブレークし、残りのロジックを後でインライン化する必要があるため、if / else-ifツリーを非常に読みやすくすることができます。

このパターンは、gotoステートメントがない言語でも役立ちます。おそらくそれが、元のプログラマーがパターンを学んだ場所です。

このようなコードを見たので、一種のコードbreakとして使用できますgoto。

これはwhile、セマティックスを取得するための単なる変態ですgoto tidy-up、gotoという単語を使用せずに。

あなたが使用している場合ので、それは悪いフォームの他の外側の内側のループを読者に曖昧になります。 「これは出口に行くことになっていますか？これは内部ループから抜け出すことのみを目的としていますか？」whilebreaks

のbreak代わりに書く方が便利だと思いますgoto end。意図を明確にするラベルの名前を考える必要もありません。特定の名前のラベルにジャンプする必要はありません。あなたはここから抜け出したいのです。

また、とにかく中かっこが必要になる可能性もあります。これがdo{...}while(false);バージョンです：

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

そしてこれはあなたが使いたいならあなたがそれを表現しなければならない方法ですgoto：

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

最初のバージョンの意味はずっと理解しやすいと思います。また、記述しやすく、拡張しやすく、サポートしていない言語に翻訳しやすくなりますgoto。

の使用に関して最も頻繁に言及される懸念breakは、それがひどく偽装されていることgotoです。しかし、実際にbreakはより類似していreturnます：両方の命令は、と比較してかなり構造化されたコードのブロックから飛び出しgotoます。それでも、どちらの命令でも、コードのブロックで複数の出口点が許可されるため、混乱を招く場合があります。結局のところ、特定の状況にあるものは何でも、最も明確な解決策を模索するように努めるでしょう。

このトリックは、恥ずかしがり屋でgotoコードで明示的に使用できないプログラマーによって使用されます。上記のコードの作成者は、コードの中央から「クリーンアップして戻る」ポイントに直接ジャンプする機能を必要としていました。しかし、彼らはラベルとエクスプリシットを使いたくありませんでしたgoto。代わりに、break上記の「フェイク」サイクルの本体の内部を使用して同じ効果を達成できます。

これは非常に一般的な方法です。ではC。私はあなたが「私は使っていない」のように自分に嘘をつくことを望んでいるかのようにそれを考えようとしますgoto。考えてみれば、goto中古同様です。実際には、インデントレベルも低下します。

とはいえ、このdo..whileループは非常に頻繁に大きくなる傾向にあります。そして、それらはifsとelsesを内部に取り込み、コードを実際には非常に読みにくくし、さらにはテスト可能にします。

これらdo..whileは通常、クリーンアップを行うためのものです。可能な限り、RAIIを使用して、短い関数から早期に戻ることをお勧めします。一方、Cは、として、あなたは非常に便利として提供されていませんC ++がない作り、最高の一つは、クリーンアップを行うに近づきます。do..while

Cプログラマのように見えます。C ++では、自動変数にクリーンアップに使用するデストラクタがあるため、戻る前に片付ける必要はありません。Cでは、このRAIIイディオムがなかったので、一般的なクリーンアップコードがある場合は、goto、それを使用する、上記のように1回限りのループを使用します。

C ++のイディオムと比較した主な欠点は、本体で例外がスローされても片付けられないことです。Cには例外がなかったため、これは問題ではありませんでしたが、C ++では悪い習慣になっています。

いくつかの説明。1つ目は一般的なもの、2つ目はパラメータ付きのCプリプロセッサマクロに固有のものです。

フロー制御

これがプレーンなCコードで使用されているのを見てきました。基本的に、それはgotoのより安全なバージョンです。それを抜け出すことができ、すべてのメモリが適切にクリーンアップされるからです。

なぜ何かgotoが良いのでしょうか？ええと、ほとんどすべての行がエラーを返す可能性があるコードがあるが、それらすべてに同じように対応する必要がある場合（たとえば、クリーンアップ後に呼び出し元にエラーを渡すことにより）、通常は、より読みやすく、if( error ) { /* cleanup and error string generation and return here */ } asます。クリーンアップコードの重複を回避します。

ただし、C ++では、この目的に例外+ RAIIがあるため、コーディングスタイルが悪いと考えます。

セミコロンチェック

関数のようなマクロ呼び出しの後にセミコロンを忘れると、引数が望ましくない方法で縮小され、有効な構文にコンパイルされる可能性があります。マクロを想像してください

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

それは誤って

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

「他」に関連しているとみなされるgDebugModeOnのでとき、fooありますfalse正確などうなることを意図したものとは逆の、。

一時変数のスコープを提供します。

do / whileには中括弧があるため、一時変数には、エスケープできない明確に定義されたスコープがあります。

「おそらく不要なセミコロン」警告の回避

一部のマクロは、デバッグビルドでのみアクティブになります。次のように定義します。

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

これを条件付きのリリースビルドで使用すると、コンパイルされます

if( foo )
    ;

多くのコンパイラはこれを

if( foo );

誤って書かれることが多い。したがって、警告が表示されます。do {} while（false）はこれをコンパイラーから隠し、本当にそれを示すものとして受け入れられますここで何もしないようにしたいです。

条件文による行のキャプチャを回避する

前の例のマクロ：

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

デバッグビルドでは、セミコロンも常用しているので、これで問題なくコンパイルできます。ただし、リリースビルドでは、これは突然次のようになります。

if( foo )

doSomething();

またはより明確にフォーマット

if( foo )
    doSomething();

これは意図されたものとはまったく異なります。マクロの周りにdo {...} while（false）を追加すると、欠落しているセミコロンがコンパイルエラーになります。

OPとはどういう意味ですか？

一般に、エラー処理にはC ++の例外を使用し、マクロの代わりにテンプレートを使用します。ただし、まだマクロが必要である（トークン貼り付けを使用してクラス名を生成する場合など）非常にまれなケースや、プレーンCに制限されている場合、これは便利なパターンです。

多分それはbreak内部で使用され、任意の時点でさらなるコードの実行を中止するために使用されます：

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

これはbreakor continueステートメントを使用するために行われたと思います。ある種の「goto」コードロジック。

それは簡単です。どうやら、breakステートメントを使用すると、いつでも偽のループから抜け出すことができます。さらに、doブロックは別のスコープです（これは、{ ... }のみで実現することもできます）。

そのような状況では、RAII（オブジェクトは、関数が終了すると自動的に正しく破壊される）を使用する方が良いでしょう。別の同様の構成はgoto- の使用です- はい、私はそれが悪であることを知っていますが、次のような一般的なクリーンアップコードを使用することができます：

<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>
}

（余談ですが、do-while-falseコンストラクトはLuaで不足しているcontinueステートメントに対処するために使用されています。）

多くの回答者がの理由を述べましたdo{(...)break;}while(false)。さらにもう1つの実際の例でこの図を補足したいと思います。

次のコードではoperation、dataポインターが指すアドレスに基づいて列挙子を設定する必要がありました。スイッチケースはスカラー型でのみ使用できるため、最初はこの方法で非効率的にしました

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

Log("operation:",operation);

しかし、Log（）と残りのコードは、選択された操作の値に対して繰り返されるため、アドレスが既に検出されている場合、残りの比較をスキップする方法を探していました。そして、これがdo{(...)break;}while(false)重宝するところです。

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

彼は同じことを行うことができなかった理由の一つは、不思議に思うかもしれbreak中ifの文のように、：

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

break単に最も近い囲むと相互作用ループ、それがあるかどうかまたはスイッチ、for、whileまたはdo .. whileタイプなので、残念ながらそれは動作しません。

著者は何歳でしたか？

80年代後半に、それを実行するリアルタイムのFortranコードに出くわしたことがあるので、質問します。それはそれらを持たないOSでスレッドをシミュレートするための本当に良い方法であることがわかりました。プログラム全体（スケジューラ）をループに入れ、「スレッド」ルーチンを1つずつ呼び出します。スレッドルーチン自体はループであり、いくつかの条件のいずれかが発生するまで繰り返されます（多くの場合、一定量の時間が経過しました。CPUを時々放棄するのは個々のスレッド次第なので、他のスレッドが枯渇しないようにする「協調マルチタスク」です。ループサブプログラム呼び出しをネストして、スレッドの優先順位をシミュレートできます。バンド。

すでに述べた「gotoの例」に加えて、do ... while（0）イディオムがマクロ定義で使用され、定義にブラケットを提供し、コンパイラーにセミコロンを末尾に追加して機能させるマクロ呼び出し。

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

私は薄く偽装した後藤としての使用法についてほとんどのポスターに同意します。マクロは、スタイルでコードを記述する潜在的な動機としても言及されています。

また、C / C ++の混在環境で使用されているこの構成体を、貧しい人の例外として見ました。「ブレーク」を伴う「do {} while（false）」を使用すると、ループで通常例外が発生することが保証されるはずのコードブロックの最後までスキップできます。

私はまた、「機能ごとの単一のリターン」のイデオロギーが実施されているショップで使用されているこの構成を使用しています。繰り返しますが、これは明示的な「goto」の代わりですが、動機は、コードを「スキップ」してその関数内で実際の実行を継続するのではなく、複数の戻り点を回避することです。

私はAdobe InDesign SDKを使用しており、InDesign SDKの例では、ほぼすべての関数がこのように記述されています。これは、通常、関数が本当に長いためです。アプリケーションオブジェクトモデルから何かを取得するためにQueryInterface（...）を実行する必要がある場合。したがって、通常、すべてのQueryInterfaceの後にifはうまくいきませんでした。

このコンストラクトとの類似性についてはすでに多くの人が述べておりgoto、gotoへの選好を表明しています。おそらく、この人物の背景には、コーディングガイドラインによってgotoが厳密に禁止されている環境が含まれていましたか？

私が考えることができるもう一つの理由はそれが飾ることです、中括弧をする、新しいC ++標準の裸の中括弧は大丈夫ではないと思います（ISO Cはそれらが好きではありません）。それ以外の場合は、lintのような静的アナライザーを停止します。

なぜそれらが必要なのか、おそらく変数スコープなのか、デバッガーの利点があるのか​​わかりません。

参照トリビアルdoループしながら、そして中括弧は良いです C2から。

私の用語を明確にするには（標準的な使用法に従っていると思います）：

裸のブレース：

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

空のブレース（NOP）：

{}

例えば

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

ブロック：

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

なるだろう

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

中括弧を削除すると、ローカル変数のスコープだけでなく、実行のフローが変更されます。したがって、「自立」または「裸」ではありません。

裸の括弧またはブロックは、マークしたい（インライン）関数の可能性があるコードのセクションを示すために使用できますが、その時点ではリファクタリングしません。

GOTOこれら2つは実質的に同一であるため、をエミュレートするための工夫された方法です。

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

そして：

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

一方、これらはどちらも実際にはifs で実行する必要があります。

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

ただし、フォワードGOTOの長い文字列をネストされたifsに変換すると、ネストが少し見苦しくなります。本当の答えは適切なリファクタリングですが、古い言語の構成要素を模倣していません。

GOTOsを含むアルゴリズムを必死に文字変換しようとした場合、おそらくこのイディオムでそれを行うことができます。それは確かに非標準であり、言語の予想されるイディオムに厳密に従っていないことを示す良い指標です。

実際、do / whileが何かのための慣用的な解決策であるCのような言語を私は知りません。

混乱全体をより理にかなった何かにリファクタリングして、より慣用的で読みやすいものにすることができます。

一部のコーダーは、関数からの出口/戻りを1つだけにすることを好みます。ダミーの使用は{....} while（false）; 完了したらダミーループを「抜け出し」、単一の戻り値を得ることができます。

私はJavaコーダーなので、私の例は次のようになります

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;
    }
}

そのような場合、私は

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

これは面白いです。他の人が言っているように、ループの内側におそらくブレークがあります。私はそれをこのようにしたでしょう：

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