title: Break-able named scopes in C/C++
body: <h2>Introduction</h2>
  
  <p>This question follows from this one : <a href="https://stackoverflow.com/questions/11005822/the-named-loop-idiom-dangerous">The named loop idiom : dangerous?</a>. For people who don't want to read the original question, it was about doing things like that :</p>
  
  <pre><code>named(label1) for(int i = 0 ; i &lt; 10 ; i++) {
      for(int j = 0 ; j &lt; 10 ; j++) {
        if(some_condition)
              break(label1); // exit outer loop
        }
  }
  </code></pre>
  
  <p>This new question is about an improved version of the "named loop" idiom. If you're too lazy to read this entire post, you can directly go to the "Example" section of this post to clearly understand what I'm talking about. </p>
  
  <h2>Design flaws</h2>
  
  <p>Unfortunately, the question was closed very quickly (and later has been re-opened) because it was more a pros/cons debate than a pure technical question. It seems that it was not fitting the SO Q&amp;A format. Moreover, the code I presented had several flaws : </p>
  
  <ul>
  <li>The keyword <code>break</code> was redefined by a macro </li>
  <li>The macro were written using lowercase letters</li>
  <li><p>It made some horrible things compilable (at least using MSVC) : </p>
  
  <pre><code>int foo() {
  
     named(label1) for(int i = 0 ; i &lt; 10; i++)
     {
        if(some_condition)
        {
            break(label1);  // here it's ok, the behavior is obvious
        }   
     }
  
     break(label1); // it compiles fine without warning... but the behavior is pretty obscur!
  
  }
  </code></pre></li>
  <li><p>It could break some good-looking code. For instance, the following is not compiling because of a scoping problem.</p>
  
  <pre><code>int foo() {
  
  named(label1)  for(int i = 0 ; i &lt; 10 ; i++)
         named(label2)  for(int j = 0 ; j &lt; 10 ; j++)
          if(i*j&lt;15)
              cout &lt;&lt; i*j &lt;&lt; endl;
          else
              break(label2);
   }
  </code></pre></li>
  </ul>
  
  <h2>A safer implementation</h2>
  
  <p>I tried to fix all these problems in order to get a <em>safe</em> version of <strong>named loops</strong>. More generally, it could also be called <strong>breakable scopes</strong> because it can be used to exit prematurely any scope, not only loops.</p>
  
  <p>Here is the definition of the two macros <code>NAMED</code> and <code>BREAK</code> :</p>
  
  <pre><code>    #define NAMED(bn)   if(const bool _YOU_CANNOT_USE_NAMED_BREAK_IF_YOU_ARE_OUTSIDE_##bn##_ = true)\
                              goto _named_loop_identifier__##bn##_;\
                          else\
                              _break_the_loop_labelled_##bn##_:\
                              if(true)\
                                  {}\
                              else\
                                  if(! _YOU_CANNOT_USE_NAMED_BREAK_IF_YOU_ARE_OUTSIDE_##bn##_)\
                                      goto _break_the_loop_labelled_##bn##_;\
                                  else\
                                      _named_loop_identifier__##bn##_:\
  
  
      #define BREAK(bn) if(!_YOU_CANNOT_USE_NAMED_BREAK_IF_YOU_ARE_OUTSIDE_##bn##_){} \
                          else goto _break_the_loop_labelled_##bn##_
  </code></pre>
  
  <p>It looks ugly &amp; cumbersome because it also avoids some warnings that could be generated by MSVC or GCC like 'unused variable', 'unreferenced label' or 'suggest explicit braces'. Moreover, it should not compile if used incorrectly, and in that case the error message will be understandable. For instance  :</p>
  
  <pre><code>    NAMED(loop1) for(int i = 0 ; i &lt; 10; i++) {
          NAMED(loop2) for(int j = 0 ; j &lt; i ; j++) {
              cout &lt;&lt; i &lt;&lt; "," &lt;&lt; j &lt;&lt; endl;
              if(j == 5) {
                  BREAK(loop1);   // this one is okay, we exit the outer loop
              }
          }
          BREAK(loop2); // we're outside loop2, this is an error
      }
  </code></pre>
  
  <p>The previous code will not compile, and the compiler error message for the second <code>BREAK</code> : '_YOU_CANNOT_USE_NAMED_BREAK_IF_YOU_ARE_OUTSIDE_loop2_` which is very explicit. </p>
  
  <h2>Example</h2>
  
  <p>Before asking my question, I provide two examples to illustrate the (relative) usefulness of those constructs :</p>
  
  <p><code>break</code> an outer loop :</p>
  
  <pre><code>     NAMED(myloop) for(int i = 0 ; i &lt; rows; i++) {
           for(int j = 0 ; j &lt; cols ; j++) {
              if(some_condition) {
                   BREAK(myloop);
              }
           }
       }
  </code></pre>
  
  <p>Exit a specific scope :</p>
  
  <pre><code>NAMED(myscope1) {
      cout&lt;&lt; "a";
      NAMED(myscope2)
      {
          cout &lt;&lt; "b";
          NAMED(myscope3)
          {
              cout &lt;&lt; "c";
              BREAK(myscope2);
              cout &lt;&lt; "d";
          }
          cout &lt;&lt; "e";
      }
      cout &lt;&lt;"f";
  }
  </code></pre>
  
  <p>This code prints : <code>abcf</code>.</p>
  
  <h2>My question</h2>
  
  <p>Before defining what my question is, I must define what it isn't since I don't want to see my topic closed in 10 minutes.</p>
  
  <p>It <strong>is not</strong> "Is it a good idea?", nor "What do you think?" or even "Is it useful?", since stackoverflow doesn't seem to be a discussion place. Anyway, I already know the answers : "Macro are evils", "Goto's are evil" &amp; "Use lambdas instead".</p>
  
  <p>Instead, my question is about technical correctness &amp; robustness against programming errors. I want this construct to be as safe as possible.</p>
  
  <ul>
  <li><p><strong>Is it possible for an user to misuse it and still be able to compile ?</strong>
  I tried to fix the obvious problems of the original implementation, but C++ is very complex and maybe I missed something ?</p></li>
  <li><p><strong>Could it silently break some good looking code ?</strong> This is my main concern. Can it interfere with the other C++ features (exception handling, destructor calls, others conditionals statements, or anything else...) ?</p></li>
  </ul>
  
  <p>My objective is to demonstrate that this construct is not <em>intrinsically</em> dangerous. I already know that it would be a very bad idea to use it in real code since others programmers may not clearly understand it, but is it safe-enough to be used in a personal project ? </p>
  
  <p>EDIT : The boolean variable is now <code>const</code> (thanks to Jens Gustedt). I'll try to replace the <code>if</code>s by <code>for</code>s later to check it can removes spurious warning when used like that : </p>
  
  <pre><code>if(true)
       BREAK(label);
  </code></pre>
  
  <p>EDIT2: As noticed by JensGustedt, variable declaration in an <code>if</code> statement is not allowed in C (C++ only). Another reason to replace it by a loop.</p>