Re: Needed features in upcoming standards

Discussion in 'C++' started by user923005, Jan 6, 2009.

  1. user923005

    user923005 Guest

    On Jan 6, 9:13 am, Blake McBride <> wrote:
    > Greetings,
    >
    > I am a long-time C programmer (close to 30 years) with very little C++
    > experience.  I don't keep up with the standards process but there are
    > two features that I've long thought needed.  It might be that C++
    > already has these features or that the upcoming standards for C or C++
    > have these features.  I suppose I'm just asking and if they are not
    > there already, I'm suggesting their addition.  They are as follows:
    >
    > 1.  Computed goto
    >
    > It would be very useful to have a computed goto.  This would involve two
    > things.  First you should be able to use labels as read-only variables.
    >   Second, you should be able to branch assign the label to an array and
    > branch to it via indexing into the array as follows:
    >
    > lbl1:
    >         ...
    > lbl2:
    >         ...
    > void *labels[] = {lbl1, lbl2};
    >
    > goto labels[x];
    >
    > The labels should not have to appear before the assignment, and there
    > should be a way of making this runtime assignment to labels once.


    Just use an array of function pointers. Easier to understand and
    debug. And if you really need to exchange them, exchange them.
    Computed gotos are a tangled mess when used without discipline. I
    shudder at some old Fortran I had to maintain in the 70's that used
    them. Eventually, I rewrote the entire mess into PL/1.

    [snip]
     
    user923005, Jan 6, 2009
    #1
    1. Advertising

  2. user923005

    Lew Pitcher Guest

    On January 6, 2009 15:05, in comp.lang.c, user923005 ()
    wrote:

    > On Jan 6, 9:13 am, Blake McBride <> wrote:
    >> Greetings,
    >>
    >> I am a long-time C programmer (close to 30 years) with very little C++
    >> experience.  I don't keep up with the standards process but there are
    >> two features that I've long thought needed.  It might be that C++
    >> already has these features or that the upcoming standards for C or C++
    >> have these features.  I suppose I'm just asking and if they are not
    >> there already, I'm suggesting their addition.  They are as follows:
    >>
    >> 1.  Computed goto
    >>
    >> It would be very useful to have a computed goto.  This would involve two
    >> things.  First you should be able to use labels as read-only variables.
    >> Second, you should be able to branch assign the label to an array and
    >> branch to it via indexing into the array as follows:
    >>
    >> lbl1:
    >> ...
    >> lbl2:
    >> ...
    >> void *labels[] = {lbl1, lbl2};
    >>
    >> goto labels[x];
    >>
    >> The labels should not have to appear before the assignment, and there
    >> should be a way of making this runtime assignment to labels once.

    >
    > Just use an array of function pointers.

    [snip]

    A dumb question: Aren't "computed gotos" already implicit in the language,
    in that they could be easily implemented (at a source-code level) using
    already-existing language constructs? I'm thinking of something like....

    {
    lbl: /* do something */

    lbl2: /* do something else */

    switch (x)
    {
    case 0: goto lbl1;
    case 1: goto lbl2;
    }
    }
    which gives the same results (AFAICT) as the OP's example.



    --
    Lew Pitcher

    Master Codewright & JOAT-in-training | Registered Linux User #112576
    http://pitcher.digitalfreehold.ca/ | GPG public key available by request
    ---------- Slackware - Because I know what I'm doing. ------
     
    Lew Pitcher, Jan 6, 2009
    #2
    1. Advertising

  3. user923005

    JC Guest

    On Jan 6, 3:37 pm, Lew Pitcher <> wrote:
    > On January 6, 2009 15:05, in comp.lang.c, user923005 ()
    > wrote:
    >
    >
    >
    > > On Jan 6, 9:13 am, Blake McBride <> wrote:
    > >> Greetings,

    >
    > >> I am a long-time C programmer (close to 30 years) with very little C++
    > >> experience.  I don't keep up with the standards process but there are
    > >> two features that I've long thought needed.  It might be that C++
    > >> already has these features or that the upcoming standards for C or C++
    > >> have these features.  I suppose I'm just asking and if they are not
    > >> there already, I'm suggesting their addition.  They are as follows:

    >
    > >> 1.  Computed goto

    >
    > >> It would be very useful to have a computed goto.  This would involve two
    > >> things.  First you should be able to use labels as read-only variables.
    > >> Second, you should be able to branch assign the label to an array and
    > >> branch to it via indexing into the array as follows:

    >
    > >> lbl1:
    > >> ...
    > >> lbl2:
    > >> ...
    > >> void *labels[] = {lbl1, lbl2};

    >
    > >> goto labels[x];

    >
    > >> The labels should not have to appear before the assignment, and there
    > >> should be a way of making this runtime assignment to labels once.

    >
    > > Just use an array of function pointers.

    >
    > [snip]
    >
    > A dumb question: Aren't "computed gotos" already implicit in the language,
    > in that they could be easily implemented (at a source-code level) using
    > already-existing language constructs?  I'm thinking of something like....
    >
    >   {
    >     lbl: /* do something */
    >
    >     lbl2: /* do something else */
    >
    >     switch (x)
    >     {
    >       case 0: goto lbl1;
    >       case 1: goto lbl2;
    >     }
    >   }
    > which gives the same results (AFAICT) as the OP's example.


    Good idea, that gives about the same results. The one thing it's
    missing is the ability to modify which label a given case jumps to at
    run time (something I'm not sure I'm comfortable with in general,
    anything that gives *nix kernel developers a means to obfuscate their
    code even more doesn't really sit well with me >:).

    Jason
     
    JC, Jan 6, 2009
    #3
  4. user923005

    user923005 Guest

    On Jan 6, 12:37 pm, Lew Pitcher <> wrote:
    > On January 6, 2009 15:05, in comp.lang.c, user923005 ()
    > wrote:
    >
    >
    >
    >
    >
    > > On Jan 6, 9:13 am, Blake McBride <> wrote:
    > >> Greetings,

    >
    > >> I am a long-time C programmer (close to 30 years) with very little C++
    > >> experience.  I don't keep up with the standards process but there are
    > >> two features that I've long thought needed.  It might be that C++
    > >> already has these features or that the upcoming standards for C or C++
    > >> have these features.  I suppose I'm just asking and if they are not
    > >> there already, I'm suggesting their addition.  They are as follows:

    >
    > >> 1.  Computed goto

    >
    > >> It would be very useful to have a computed goto.  This would involve two
    > >> things.  First you should be able to use labels as read-only variables.
    > >> Second, you should be able to branch assign the label to an array and
    > >> branch to it via indexing into the array as follows:

    >
    > >> lbl1:
    > >> ...
    > >> lbl2:
    > >> ...
    > >> void *labels[] = {lbl1, lbl2};

    >
    > >> goto labels[x];

    >
    > >> The labels should not have to appear before the assignment, and there
    > >> should be a way of making this runtime assignment to labels once.

    >
    > > Just use an array of function pointers.

    >
    > [snip]
    >
    > A dumb question: Aren't "computed gotos" already implicit in the language,
    > in that they could be easily implemented (at a source-code level) using
    > already-existing language constructs?  I'm thinking of something like....
    >
    >   {
    >     lbl: /* do something */
    >
    >     lbl2: /* do something else */
    >
    >     switch (x)
    >     {
    >       case 0: goto lbl1;
    >       case 1: goto lbl2;
    >     }
    >   }
    > which gives the same results (AFAICT) as the OP's example.


    Quite likely it is what the O.P. meant.
    In Fortran, there is also the ability to modify the label in a
    variable that you are jumping to. Of course, that's Icky[tm].

    If the O.P. needs to write a state machine, there are tools to help
    with that.
     
    user923005, Jan 7, 2009
    #4
  5. user923005

    JC Guest

    On Jan 6, 4:38 pm, Blake McBride <> wrote:
    > Lew Pitcher wrote:
    > > A dumb question: Aren't "computed gotos" already implicit in the language,
    > > in that they could be easily implemented (at a source-code level) using
    > > already-existing language constructs?  I'm thinking of something like....

    >
    > >   {
    > >     lbl: /* do something */

    >
    > >     lbl2: /* do something else */

    >
    > >     switch (x)
    > >     {
    > >       case 0: goto lbl1;
    > >       case 1: goto lbl2;
    > >     }
    > >   }
    > > which gives the same results (AFAICT) as the OP's example.

    >
    > Except that you are missing the point that I am trying to avoid the
    > potential overhead of the switch statement (which could/would be VERY
    > significant in a VM.)


    Specifically, the overhead you are trying to avoid, assuming that the
    compiler generates a jump table from the switch, is the overhead of a
    range check.

    1. No language change would guarantee that indexing into a computed
    goto array doesn't perform a range check (although it's unlikely a
    compiler would implement it as such, there's nothing stopping it from
    doing so).

    2. Some compilers have extensions that can help you optimize that
    away (e.g. __assume() in MSVC). You can take advantage of compiler-
    specific extensions (note that *all* optimizations are compiler-
    specific) when available to get the performance you need.

    I've added comp.lang.c back to the reply list.
     
    JC, Jan 7, 2009
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Omnicore Software
    Replies:
    1
    Views:
    445
    Tim Tyler
    Sep 29, 2003
  2. Jonathan Mcdougall
    Replies:
    2
    Views:
    514
    Kaz Kylheku
    Nov 3, 2005
  3. David Lee

    Features and standards

    David Lee, Mar 11, 2008, in forum: C Programming
    Replies:
    19
    Views:
    720
    Keith Thompson
    Mar 16, 2008
  4. Willem
    Replies:
    25
    Views:
    714
    Keith Thompson
    Jan 9, 2009
  5. Willem

    Re: Needed features in upcoming standards

    Willem, Jan 6, 2009, in forum: C Programming
    Replies:
    26
    Views:
    626
    Spiros Bousbouras
    Jan 10, 2009
Loading...

Share This Page