u misunderstand

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Bern

    u misunderstand

    i think i wasn't clear enough or you misunderstood.

    continue the "big" loop means reset to the beginning of the "big" loop,
    which means the condition of the big loop is evaluated , -- as if
    the program has just entered the loop.

    for example:

    while (some condition){

    if (condition) continue; //// continue means reset to the beginning
    of the loop.

    if (another ...){

    some code;
    }
    }


    if there is such thing as labeled continue,
    we can do the following:
    ----------------------------------------------------
    big_loop:

    while (...){

    some code;

    while (...){

    /*
    continue big_loop means reset to the beginning
    of big loop.
    it means exactly "goto big_loop" here.
    */
    if (....) continue big_loop;

    }

    }

    however, C/C++ does not support labeled continue and breaks.

    i know labeled continue and breaks can be replaced by "gotos",
    but, such useful feature why doesn't C++ support?

    i think labeled continue and breaks are similar to goto, thats why
    the creators of C++ doesn't want to include this feature, since they
    are already discouraging the use of goto.

    then it comes to this question: Can we really do without gotos??





  • Ivan Vecerina

    #2
    Re: u misunderstand

    " Bern" <x@x.com> wrote in message news:41384968$1 @news.starhub.n et.sg...[color=blue]
    > if there is such thing as labeled continue,
    > we can do the following:
    > ----------------------------------------------------
    > big_loop:
    >
    > while (...){
    >
    > some code;
    >
    > while (...){
    >
    > /*
    > continue big_loop means reset to the beginning
    > of big loop.
    > it means exactly "goto big_loop" here.
    > */
    > if (....) continue big_loop;
    >
    > }
    >
    > }
    >
    > however, C/C++ does not support labeled continue and breaks.[/color]

    In the instance above, you can replace "continue big_loop;"
    with "break;" -- this will have the same effect.

    If there is code after the inner loop that should not
    be executed when continuing to the outer loop, however,
    you may need to add a flag/test;
    bool skip = false;
    while (...){
    some code;
    while (...){
    if (....) { skip = true; break; }
    }
    if(skip) skip=false;
    else {
    /* some code to be skipped by break/"continue" */
    }
    }
    [color=blue]
    > i know labeled continue and breaks can be replaced by "gotos",
    > but, such useful feature why doesn't C++ support?[/color]
    Because it is not that much better / more informative than
    a simple goto.
    Actually, the problem above can better be solved by a syntax
    supported in Python: an else clause at the end of a loop,
    which is executed only when the loop exists because its
    condition is false.
    This leads to the following code:

    while (...){
    some code;
    while (...){
    if (....) break;
    }
    else {
    /* some code to be skipped by break/"continue" */
    }
    }

    I find this more elegant than a labeled continue...
    [color=blue]
    > i think labeled continue and breaks are similar to goto, thats why
    > the creators of C++ doesn't want to include this feature, since they
    > are already discouraging the use of goto.[/color]
    The designers of C and C++ are not the only ones to discourage gotos!
    However, gotos do have few acceptable uses.
    What happened is that developers of e.g. Java have decided to
    only implement gotos in the situations that were seen as 'acceptable'.
    [color=blue]
    > then it comes to this question: Can we really do without gotos??[/color]

    Yes. A few languages don't have them, but remain usable.
    The problem with gotos is that they get abused, and one
    should always look for alternatives.


    hth-Ivan
    --
    http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
    Brainbench MVP for C++ <> http://www.brainbench.com





    Comment

    • Phlip

      #3
      Re: u misunderstand

      Bern wrote:
      [color=blue]
      > i think i wasn't clear enough or you misunderstood.
      >
      > continue the "big" loop means reset to the beginning of the "big" loop,
      > which means the condition of the big loop is evaluated , -- as if
      > the program has just entered the loop.
      >
      > for example:
      >
      > while (some condition){
      >
      > if (condition) continue; //// continue means reset to the[/color]
      beginning[color=blue]
      > of the loop.
      >
      > if (another ...){
      >
      > some code;
      > }
      > }
      >
      >
      > if there is such thing as labeled continue,
      > we can do the following:
      > ----------------------------------------------------
      > big_loop:
      >
      > while (...){
      >
      > some code;
      >
      > while (...){
      >
      > /*
      > continue big_loop means reset to the beginning
      > of big loop.
      > it means exactly "goto big_loop" here.
      > */
      > if (....) continue big_loop;
      >
      > }
      >
      > }
      >
      > however, C/C++ does not support labeled continue and breaks.[/color]

      That's because functions shouldn't contain so many statements. If the inner
      loop were inside a method, it could use 'return' to reenter the outer loop.
      [color=blue]
      > then it comes to this question: Can we really do without gotos??[/color]

      Don't blame the symptom.

      --
      Phlip



      Comment

      • Andrew Koenig

        #4
        Re: u misunderstand

        " Bern" <x@x.com> wrote in message news:41384968$1 @news.starhub.n et.sg...
        [color=blue]
        > i know labeled continue and breaks can be replaced by "gotos",
        > but, such useful feature why doesn't C++ support?[/color]

        Perhaps the feature is not as useful as you think it is.

        The existence of such a feature makes it much more difficult to reason about
        programs, because it implies that the effect of

        statement1;
        statement2;

        might not be the same as the effect of statement1 followed by the effect of
        statement2.

        Perhaps you should try writing an actual piece of code that would use your
        ideal feature. Then we could examine the code, point out what we think is
        good and not so good about it, and suggest alternatives. As it is, we don't
        have much to use as a basis for discussion.


        Comment

        • Bern

          #5
          Re: u misunderstand

          > while (...){[color=blue]
          > if (....) { skip = true; break; }
          > }
          > if(skip) skip=false;
          > else {
          > /* some code to be skipped by break/"continue" */
          > }[/color]

          you waste time executing the" if (skip) skip=false" statement.
          it would be better if the program jumps directly to the outer loop

          "Ivan Vecerina" <NOT_VALID_plea se_use_contact_ webform@vecerin a.com> wrote in
          message news:ch9j3v$tnj $1@newshispeed. ch...[color=blue]
          > " Bern" <x@x.com> wrote in message news:41384968$1 @news.starhub.n et.sg...[color=green]
          > > if there is such thing as labeled continue,
          > > we can do the following:
          > > ----------------------------------------------------
          > > big_loop:
          > >
          > > while (...){
          > >
          > > some code;
          > >
          > > while (...){
          > >
          > > /*
          > > continue big_loop means reset to the beginning
          > > of big loop.
          > > it means exactly "goto big_loop" here.
          > > */
          > > if (....) continue big_loop;
          > >
          > > }
          > >
          > > }
          > >
          > > however, C/C++ does not support labeled continue and breaks.[/color]
          >
          > In the instance above, you can replace "continue big_loop;"
          > with "break;" -- this will have the same effect.
          >
          > If there is code after the inner loop that should not
          > be executed when continuing to the outer loop, however,
          > you may need to add a flag/test;
          > bool skip = false;
          > while (...){
          > some code;
          > while (...){
          > if (....) { skip = true; break; }
          > }
          > if(skip) skip=false;
          > else {
          > /* some code to be skipped by break/"continue" */
          > }
          > }
          >[color=green]
          > > i know labeled continue and breaks can be replaced by "gotos",
          > > but, such useful feature why doesn't C++ support?[/color]
          > Because it is not that much better / more informative than
          > a simple goto.
          > Actually, the problem above can better be solved by a syntax
          > supported in Python: an else clause at the end of a loop,
          > which is executed only when the loop exists because its
          > condition is false.
          > This leads to the following code:
          >
          > while (...){
          > some code;
          > while (...){
          > if (....) break;
          > }
          > else {
          > /* some code to be skipped by break/"continue" */
          > }
          > }
          >
          > I find this more elegant than a labeled continue...
          >[color=green]
          > > i think labeled continue and breaks are similar to goto, thats why
          > > the creators of C++ doesn't want to include this feature, since they
          > > are already discouraging the use of goto.[/color]
          > The designers of C and C++ are not the only ones to discourage gotos!
          > However, gotos do have few acceptable uses.
          > What happened is that developers of e.g. Java have decided to
          > only implement gotos in the situations that were seen as 'acceptable'.
          >[color=green]
          > > then it comes to this question: Can we really do without gotos??[/color]
          >
          > Yes. A few languages don't have them, but remain usable.
          > The problem with gotos is that they get abused, and one
          > should always look for alternatives.
          >
          >
          > hth-Ivan
          > --
          > http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
          > Brainbench MVP for C++ <> http://www.brainbench.com
          >
          >
          >
          >
          >[/color]


          Comment

          • Ivan Vecerina

            #6
            Re: u misunderstand

            > "Ivan Vecerina" <NOT_VALID_plea se_use_contact_ webform@vecerin a.com> wrote
            in[color=blue]
            > message news:ch9j3v$tnj $1@newshispeed. ch...[/color]
            " Bern" <x@x.com> wrote in message news:413959b4$1 @news.starhub.n et.sg...[color=blue][color=green]
            > > while (...){
            > > if (....) { skip = true; break; }
            > > }
            > > if(skip) skip=false;
            > > else {
            > > /* some code to be skipped by break/"continue" */
            > > }[/color]
            > you waste time executing the" if (skip) skip=false" statement.
            > it would be better if the program jumps directly to the outer loop[/color]

            Cases where this "waste of time" is measurably significant will be few.
            But the real question is, what is better for clarity/maintainability :
            adding such a dispatch flag, or actually using a goto?

            In such a situation, I do prefer using a goto than either of the
            commonly seen workarounds ( adding a flag or a throw-catch) :
            [color=blue][color=green]
            > > However, gotos do have few acceptable uses.
            > > What happened is that developers of e.g. Java have decided to
            > > only implement gotos in the situations that were seen as 'acceptable'.[/color][/color]
            ....[color=blue][color=green]
            > > The problem with gotos is that they get abused, and one
            > > should always look for alternatives.[/color][/color]

            This said, nested loops bring possibly unnecessary complexity.
            Given a concrete example, we could explore refactorings/redesigns
            that can advantageously replace a goto.

            NB:
            The worst loop nesting I ever saw in a review was 7-level deep !
            There is no way I would have let this into a check-in...


            Cheers,
            Ivan
            --
            http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form


            Comment

            Working...