Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #96466 > unrolled thread

Minimum amount of syntax for C language

Back to article view | Back to comp.lang.c

Contents

  Minimum amount of syntax for C language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-13 18:56 +0800
    Re: Minimum amount of syntax for C language BartC <bc@freeuk.com> - 2016-11-13 11:26 +0000
      [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-13 19:41 +0800
        Re: [OT] BartC <bc@freeuk.com> - 2016-11-13 12:42 +0000
          Minimum amount of syntax for C language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-13 20:45 +0800
            Re: Minimum amount of syntax for C language jameskuyper@verizon.net - 2016-11-13 07:42 -0800
              Re: Minimum amount of syntax for C language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-14 00:01 +0800
                Re: Minimum amount of syntax for C language jameskuyper@verizon.net - 2016-11-13 10:00 -0800
                Re: Minimum amount of syntax for C language "Osmium" <r124c4u102@comcast.net> - 2016-11-13 13:16 -0600
                  Re: Minimum amount of syntax for C language BartC <bc@freeuk.com> - 2016-11-13 19:28 +0000
                    Re: Minimum amount of syntax for C language Thiago Adams <thiago.adams@gmail.com> - 2016-11-14 08:10 -0800
                Re: Minimum amount of syntax for C language John Bode <jfbode1029@gmail.com> - 2016-11-14 12:34 -0800
                Re: Minimum amount of syntax for C language "Osmium" <r124c4u102@comcast.net> - 2016-11-16 10:22 -0600
                  Re: Minimum amount of syntax for C language supercat@casperkitty.com - 2016-11-16 08:33 -0800
                  Re: Minimum amount of syntax for C language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-17 22:11 +0800
                    Re: Minimum amount of syntax for C language BartC <bc@freeuk.com> - 2016-11-17 16:30 +0000
                      Re: Minimum amount of syntax for C language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 01:05 +0800
                  Re: Minimum amount of syntax for C language John Bode <jfbode1029@gmail.com> - 2016-11-17 09:03 -0800
                    Re: Minimum amount of syntax for C language Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-17 13:58 -0500
                      Re: Minimum amount of syntax for C language BartC <bc@freeuk.com> - 2016-11-17 19:10 +0000
                        Re: Minimum amount of syntax for C language Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-17 17:41 -0500
                    Re: Minimum amount of syntax for C language Thiago Adams <thiago.adams@gmail.com> - 2016-11-17 11:03 -0800
                      Re: Minimum amount of syntax for C language Keith Thompson <kst-u@mib.org> - 2016-11-17 11:56 -0800
                        Re: Minimum amount of syntax for C language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-17 12:17 -0800
                        Re: Minimum amount of syntax for C language Thiago Adams <thiago.adams@gmail.com> - 2016-11-17 12:21 -0800

Page 2 of 2 — ← Prev page 1 [2]

#96780

On 11/17/2016 2:10 PM, BartC wrote:
> On 17/11/2016 18:58, Jerry Stuckle wrote:
>> On 11/17/2016 12:03 PM, John Bode wrote:
>>> On Wednesday, November 16, 2016 at 10:22:23 AM UTC-6, Osmium wrote:
>>>> "Mr. Man-wai Chang" wrote:
>>>>
>>>>> For teaching purposes, do you need complete and full C syntax? DO
>>>>> you need
>>>>> a sophiscated compiler?
>>>>
>>>> On further thought, I can't think of any situation where the goto
>>>> statement is required.
>>>
>>> Not *required*, but one place where it is useful (and not immediately a
>>> sign of poor design or practice) is bailing out of a deeply nested loop
>>> or multi-step resource allocation process:
>>>
>>>     for ( ... )
>>>       for ( ... )
>>>         for ( ... )
>>>           if ( some_error )
>>>             goto exit:
>>>
>>>     exit: // clean up
>>>
>>> Obviously, you'll want to structure your code such that you avoid that
>>> situation, but sometimes it simply isn't possible (or, the level of
>>> effort required to do so is not worth the tradeoff).
>>>
>>
>> Or,
>>
>>    bool exit = false;
>>    for (... && !exit)
>>       for (... && !exit)
>>      for (... && !exit)
>>             if (some_error) {
>>             exit = true;
>>                 break;
>>             }
>>
>> Clean easy to understand and no goto.
> 
> But it won't do the same thing. Suppose there is extra code after each
> loop:
> 
>      for ( ... ) {
>        for ( ... ) {
>          for ( ... ) {
>            if ( some_error )
>              goto exit:
>          }
>          A;
>        }
>        B;
>      }
>      C;
> // clean up ...
> 
> With your scheme, A and B will still be executed before it quits the
> outer loop, and C will be executed on exit from the outer loop.
> 
> Apart from which you don't your code cluttered up with all this extra
> logic.
> 

That wasn't part of the original question.  I satisfied what you asked
for.  And it's better to have structured code than goto's.  In over 30
years of C coding I have NEVER had a NEED for a goto - and neither have
any or the projects I've worked on.

But there are other ways to do what you want.  I'll leave it up to you
to find them; I'm not going to keep hitting your moving target.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#96761

On Thursday, November 17, 2016 at 3:03:40 PM UTC-2, John Bode wrote:
> On Wednesday, November 16, 2016 at 10:22:23 AM UTC-6, Osmium wrote:
> > "Mr. Man-wai Chang" wrote:
> > 
> > > For teaching purposes, do you need complete and full C syntax? DO you need 
> > > a sophiscated compiler?
> > 
> > On further thought, I can't think of any situation where the goto 
> > statement is required.
> 
> Not *required*, but one place where it is useful (and not immediately a
> sign of poor design or practice) is bailing out of a deeply nested loop
> or multi-step resource allocation process:
> 
>     for ( ... )
>       for ( ... )
>         for ( ... )
>           if ( some_error )
>             goto exit:
> 
>     exit: // clean up
> 
> Obviously, you'll want to structure your code such that you avoid that
> situation, but sometimes it simply isn't possible (or, the level of
> effort required to do so is not worth the tradeoff).

The other option to exit is add an external do {} while(0) and break.

do
{
if ()
{
 if ()
  {
   if ()
   {
     break; //ok
   }
  }
 }
} while(0);

I think should be nice to have:

ctry
{
   if (result == error) cthrow result;
}
ccatch (Result error)
{

}

//This is not a C++ throw , its a goto do catch point with an argument

[toc] | [prev] | [next] | [standalone]

#96765

Thiago Adams <thiago.adams@gmail.com> writes:
> On Thursday, November 17, 2016 at 3:03:40 PM UTC-2, John Bode wrote:
[...]
>> Not *required*, but one place where it is useful (and not immediately a
>> sign of poor design or practice) is bailing out of a deeply nested loop
>> or multi-step resource allocation process:
>> 
>>     for ( ... )
>>       for ( ... )
>>         for ( ... )
>>           if ( some_error )
>>             goto exit:
>> 
>>     exit: // clean up
>> 
>> Obviously, you'll want to structure your code such that you avoid that
>> situation, but sometimes it simply isn't possible (or, the level of
>> effort required to do so is not worth the tradeoff).
>
> The other option to exit is add an external do {} while(0) and break.
>
> do
> {
> if ()
> {
>  if ()
>   {
>    if ()
>    {
>      break; //ok
>    }
>   }
>  }
> } while(0);

That's not helpful if you need to bail out of multiple nested loops.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#96770

On Thursday, November 17, 2016 at 2:55:00 PM UTC-5, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> > On Thursday, November 17, 2016 at 3:03:40 PM UTC-2, John Bode wrote:
> [...]
> >> Not *required*, but one place where it is useful (and not immediately a
> >> sign of poor design or practice) is bailing out of a deeply nested loop
> >> or multi-step resource allocation process:
> >> 
> >>     for ( ... )
> >>       for ( ... )
> >>         for ( ... )
> >>           if ( some_error )
> >>             goto exit:
> >> 
> >>     exit: // clean up
> >> 
> >> Obviously, you'll want to structure your code such that you avoid that
> >> situation, but sometimes it simply isn't possible (or, the level of
> >> effort required to do so is not worth the tradeoff).
> >
> > The other option to exit is add an external do {} while(0) and break.
> >
> > do
> > {
> > if ()
> > {
> >  if ()
> >   {
> >    if ()
> >    {
> >      break; //ok
> >    }
> >   }
> >  }
> > } while(0);
> 
> That's not helpful if you need to bail out of multiple nested loops.

I addressed this issue in CAlive using a new concept called a flow{}.
Flows are created to give unstructured code structure.

    flow {
        for ( ... )
          for ( ... )
            for ( ... )
              if ( some_error )
                flowto finished;

    } finished {
        // clean up
    }

In this case, it's attached to the block of code, it's labeled, it's
fully encapsulated within its { } block, intuitive in operation, and
easy to see how it relates to the otherwise unstructured goto ability,
but in a structured way.

Each additional flow can then be added using more labels, and if there
are common blocks of code that should be called, define them like a
function, as in:

    flow {
        example(a);
        if (test)
            example(b);

    } void example(int x) {
        // Code here for example
        // Use return keyword to return
        // Also, use flowout keyword to exit the flow
    }

The only new requirement is that if flow blocks are used, the block
using them must be semicolon terminated (which is not shown above as
those were for illustrative purposes only).

CAlive also allows un-nested flow blocks, to remove code from the much-
indented location, and pull it back out, and then give it a name.  In
those cases, they use the {{ and }} for block markers.

See:

    CAlive to introduce flow { } blocks:
    https://groups.google.com/d/msg/caliveprogramminglanguage/pSV7rzGcIeE/Ix3pBmhsBgAJ

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#96773

On Thursday, November 17, 2016 at 5:55:00 PM UTC-2, Keith Thompson wrote:
> Thiago Adams  writes:
> > On Thursday, November 17, 2016 at 3:03:40 PM UTC-2, John Bode wrote:
> [...]
> >> Not *required*, but one place where it is useful (and not immediately a
> >> sign of poor design or practice) is bailing out of a deeply nested loop
> >> or multi-step resource allocation process:
> >> 
> >>     for ( ... )
> >>       for ( ... )
> >>         for ( ... )
> >>           if ( some_error )
> >>             goto exit:
> >> 
> >>     exit: // clean up
> >> 
> >> Obviously, you'll want to structure your code such that you avoid that
> >> situation, but sometimes it simply isn't possible (or, the level of
> >> effort required to do so is not worth the tradeoff).
> >
> > The other option to exit is add an external do {} while(0) and break.
> >
> > do
> > {
> > if ()
> > {
> >  if ()
> >   {
> >    if ()
> >    {
> >      break; //ok
> >    }
> >   }
> >  }
> > } while(0);
> 
> That's not helpful if you need to bail out of multiple nested loops.

Sure.
I think the "ifs" are more common than nested loops.

I see some patterns.

result = F1();
if (result != ok) goto errorlabel; 
result = F2();
if (result != ok) goto errorlabel; 
result = FN();

if (result == ok)
  return result;
errorlabel:

---

result = F1()
if (result == ok)
{
  result = F2()
  if (result == ok)
  {
     ....
  }
}
return result;


When you have object initialization it's different:

With the errorlabel pattern you can initialize everything with null/empty (destructible state) and then clear destroy everything.

Object1 obj1 = EMPTY_STATE;
Object2 obj2 = EMPTY_STATE;

result = F1();
if (result != ok) goto errorlabel; 
result = F2();
if (result != ok) goto errorlabel; 
result = FN();

Object1_Destroy(&obj1);
Object2_Destroy(&obj2);

if (result == ok)
  return result;

errorlabel:

Object1_Destroy(&obj1);
Object2_Destroy(&obj2);

What I don't like on this pattern is that the code has two points of destruction.

The "if pattern" you the object live can start/end inside the scope.

result = F1(&obj1)
if (result == ok)
{
  result = F2(&obj2)
  if (result == ok)
  {
     ....
    Destroy(&obj2);
  }
  Destroy(&obj1);
}
return result;



and 

Object1 obj1 = EMPTY_STATE;
Object2 obj2 = EMPTY_STATE;


result = Init(&obj1)
if (result == ok)
{
  result = Init(&obj2)
  if (result == ok)
  {
     ....

  }

}

 Destroy(&obj2);
 Destroy(&obj1);

return result;

The disadvantage of this latter pattern is that you put an object in one state and them change. Sometimes is hard to find the empty state.

The advantage is that is very easy to follow. The destruction is at the same scope of variable. (Very easy to create an static analysis check)

Which pattern do you prefer/use?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web