Simple doubt about blocks

Discussion in 'C Programming' started by Sensei, Mar 26, 2008.

  1. Sensei

    Sensei Guest

    Hi again! Another probably silly question. I have been reading the
    standard but I didn't find anything about this, at a first glance.

    What does the standard say about inserting code blocks? I think the
    following is valid C:

    printf("hello\n");
    {
    printf("world\n");
    }

    I am thinking about the use of code blocks in order to help readability
    of code that make use of "modal" function calls. One example is OpenGL:

    glBegin(whatever);
    glFunction1(x);
    glFunction2(y);
    ....
    glEnd();

    which can be rewritten as

    glBegin(whatever);
    {
    glFunction1(x);
    glFunction2(y);
    ...
    }
    glEnd();


    Do you see anything bad about this convention? What would be the
    difference for the compiler in those two cases?

    Thanks!


    PS. I know opengl is OT, but functions like glBegin() and glEnd() can
    be used in many codes. I am worried about the adherence to the standard
    C, not to OpenGL or any other library. The example is here just to help
    in case one knows how OpenGL should be used.

    --

    Sensei <Sensei's e-mail is at Mac-dot-com>

    It is a very sad thing that nowadays there is so little useless information.
    (Oscar Wilde)
     
    Sensei, Mar 26, 2008
    #1
    1. Advertising

  2. Sensei <Sensei's e-mail is at Mac-dot-com> said:

    > What does the standard say about inserting code blocks? I think the
    > following is valid C:
    >
    > printf("hello\n");
    > {
    > printf("world\n");
    > }


    It is.

    > I am thinking about the use of code blocks in order to help readability
    > of code that make use of "modal" function calls. One example is OpenGL:
    >
    > glBegin(whatever);
    > glFunction1(x);
    > glFunction2(y);
    > ...
    > glEnd();
    >
    > which can be rewritten as
    >
    > glBegin(whatever);
    > {
    > glFunction1(x);
    > glFunction2(y);
    > ...
    > }
    > glEnd();
    >
    >
    > Do you see anything bad about this convention?


    No.

    > What would be the
    > difference for the compiler in those two cases?


    If you don't define any objects within the block, there is no practical
    difference. And even if you do, well, the compiler will just have to cope.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Mar 26, 2008
    #2
    1. Advertising

  3. Sensei

    santosh Guest

    Sensei <Sensei's e-mail is at Mac-dot-com> wrote:

    > Hi again! Another probably silly question. I have been reading the
    > standard but I didn't find anything about this, at a first glance.
    >
    > What does the standard say about inserting code blocks? I think the
    > following is valid C:
    >
    > printf("hello\n");
    > {
    > printf("world\n");
    > }


    A code block is a compound statement that is treated by C as a single
    statement. It introduces a new scope.

    > I am thinking about the use of code blocks in order to help
    > readability of code that make use of "modal" function calls. One
    > example is OpenGL:
    >
    > glBegin(whatever);
    > glFunction1(x);
    > glFunction2(y);
    > ...
    > glEnd();
    >
    > which can be rewritten as
    >
    > glBegin(whatever);
    > {
    > glFunction1(x);
    > glFunction2(y);
    > ...
    > }
    > glEnd();
    >
    >
    > Do you see anything bad about this convention? What would be the
    > difference for the compiler in those two cases?


    Well, if you declare variables within the code block, you have to be
    aware that they will only be available within the block and may take
    precedence over identical identifiers in a outer scope.

    Personally I wouldn't use code blocks merely for readability, but to
    each his own I guess. I would use them when I need a few variables for
    a short sequence of statements, but I don't want to declare them at
    function scope and have them persist throughout the function, open to
    inadvertent access. A code block helps in this case.

    Also be aware that if you declare and use VLAs within a compound
    statement, you are disallowed to jump past their declarations with a
    goto.

    <snip>
     
    santosh, Mar 26, 2008
    #3
  4. Sensei

    Chris Dollin Guest

    Sensei <Sensei's e-mail is at Mac-dot-com> wrote:
    > I am thinking about the use of code blocks in order to help readability
    > of code that make use of "modal" function calls. One example is OpenGL:
    >
    > glBegin(whatever);
    > glFunction1(x);
    > glFunction2(y);
    > ...
    > glEnd();
    >
    > which can be rewritten as
    >
    > glBegin(whatever);
    > {
    > glFunction1(x);
    > glFunction2(y);
    > ...
    > }
    > glEnd();
    >
    >
    > Do you see anything bad about this convention?


    IMAO: it's pointless. If I wanted to do something like that,
    I'd abstract those two functions into another one with a
    useful name.

    --
    "Thereafter, events may roll unheeded." /Foundation/

    Hewlett-Packard Limited Cain Road, Bracknell, registered no:
    registered office: Berks RG12 1HN 690597 England
     
    Chris Dollin, Mar 26, 2008
    #4
  5. Chris Dollin said:

    > Sensei <Sensei's e-mail is at Mac-dot-com> wrote:
    >> I am thinking about the use of code blocks in order to help readability
    >> of code that make use of "modal" function calls. One example is OpenGL:
    >>
    >> glBegin(whatever);
    >> glFunction1(x);
    >> glFunction2(y);
    >> ...
    >> glEnd();
    >>
    >> which can be rewritten as
    >>
    >> glBegin(whatever);
    >> {
    >> glFunction1(x);
    >> glFunction2(y);
    >> ...
    >> }
    >> glEnd();
    >>
    >>
    >> Do you see anything bad about this convention?

    >
    > IMAO: it's pointless.


    Isn't that just a touch A, Chris? :) It may not be your cup of tea, but
    style is a very personal thing. I'm not saying I'd necessarily do it the
    way he is doing it, but I can certainly see where he's coming from.


    > If I wanted to do something like that,
    > I'd abstract those two functions into another one with a
    > useful name.


    Can you demonstrate to the OP how you would do that?

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Mar 26, 2008
    #5
  6. Sensei

    Chris Dollin Guest

    Richard Heathfield wrote:

    > Chris Dollin said:
    >
    >> Sensei <Sensei's e-mail is at Mac-dot-com> wrote:
    >>> I am thinking about the use of code blocks in order to help readability
    >>> of code that make use of "modal" function calls. One example is OpenGL:
    >>>
    >>> glBegin(whatever);
    >>> glFunction1(x);
    >>> glFunction2(y);
    >>> ...
    >>> glEnd();
    >>>
    >>> which can be rewritten as
    >>>
    >>> glBegin(whatever);
    >>> {
    >>> glFunction1(x);
    >>> glFunction2(y);
    >>> ...
    >>> }
    >>> glEnd();
    >>>
    >>>
    >>> Do you see anything bad about this convention?

    >>
    >> IMAO: it's pointless.

    >
    > Isn't that just a touch A, Chris? :)


    As you noticed, Bob\\\Richard, I said so myself.

    > It may not be your cup of tea, but
    > style is a very personal thing. I'm not saying I'd necessarily do it the
    > way he is doing it, but I can certainly see where he's coming from.


    I see what he's trying to do: I just think that it doesn't
    express that, and that it reads as clutter, not content. There
    are too many things that a declarationless block means (eg,
    "I forgot the declaration", "I forgot the if", "I forgot to
    tidy up after that cut'n'paste") for it to be a reliable indicator
    of "these are the things I'm modally doing".

    >> If I wanted to do something like that,
    >> I'd abstract those two functions into another one with a
    >> useful name.

    >
    > Can you demonstrate to the OP how you would do that?


    Yes.

    (fx:beat)

    Oh, right, /now/.

    Replace

    glFunction1(x);
    glFunction2(y);

    with

    aProperNameForThisModalGroup();

    defining

    static void aPropertNameForThisModalGroup()
    {
    glFunction1(x);
    glFunction2(y);
    }

    [Layout/namingConvention to taste, natch.]

    Of course as soon as I'd done this a few [1] times I'd go

    void executeModalGroup( void (*group)(void) )
    {
    glBegin( whatever );
    group();
    glEnd();
    }

    and replace the original

    >>> glBegin(whatever);
    >>> glFunction1(x);
    >>> glFunction2(y);
    >>> ...
    >>> glEnd();


    with

    executeModelGroup( aProperNameForThisModelGroup );

    Decorate with parameters as necessary.

    [1] Two. Or maybe even one. Opinions differ.

    --
    "Your world, Colonel, and I wish you the best of it!" /Witch World/

    Hewlett-Packard Limited Cain Road, Bracknell, registered no:
    registered office: Berks RG12 1HN 690597 England
     
    Chris Dollin, Mar 26, 2008
    #6
  7. On 26 Mar 2008 at 8:13, santosh wrote:
    > Also be aware that if you declare and use VLAs within a compound
    > statement, you are disallowed to jump past their declarations with a
    > goto.


    Something I think we all want to do every day - thanks for pointing that
    out!
     
    Antoninus Twink, Mar 26, 2008
    #7
  8. On 26 Mar 2008 at 9:04, Chris Dollin wrote:
    > Sensei <Sensei's e-mail is at Mac-dot-com> wrote:
    >> I am thinking about the use of code blocks in order to help readability
    >> of code that make use of "modal" function calls. One example is OpenGL:
    >>
    >> glBegin(whatever);
    >> glFunction1(x);
    >> glFunction2(y);
    >> ...
    >> glEnd();
    >>
    >> which can be rewritten as
    >>
    >> glBegin(whatever);
    >> {
    >> glFunction1(x);
    >> glFunction2(y);
    >> ...
    >> }
    >> glEnd();
    >>
    >>
    >> Do you see anything bad about this convention?

    >
    > IMAO: it's pointless. If I wanted to do something like that,
    > I'd abstract those two functions into another one with a
    > useful name.


    You mean, into a macro, to avoid the extra function call overhead.
     
    Antoninus Twink, Mar 26, 2008
    #8
  9. Sensei

    Chris Dollin Guest

    Antoninus Twink wrote:

    >> IMAO: it's pointless. If I wanted to do something like that,
    >> I'd abstract those two functions into another one with a
    >> useful name.

    >
    > You mean, into a macro, to avoid the extra function call overhead.


    No, I do /not/ mean a macro; if I'd meant to include that case, I'd
    have said so.

    --
    "Let's finish this. Lord Vorkosigan!" /A Civil Campaign/

    Hewlett-Packard Limited registered no:
    registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
     
    Chris Dollin, Mar 26, 2008
    #9
  10. Sensei

    Bartc Guest

    "Chris Dollin" <> wrote in message
    news:fsd8ce$35o$...
    > Richard Heathfield wrote:
    >
    >> Chris Dollin said:
    >>
    >>> Sensei <Sensei's e-mail is at Mac-dot-com> wrote:
    >>>> I am thinking about the use of code blocks in order to help readability
    >>>> of code that make use of "modal" function calls. One example is OpenGL:
    >>>>
    >>>> glBegin(whatever);
    >>>> glFunction1(x);
    >>>> glFunction2(y);
    >>>> ...
    >>>> glEnd();
    >>>>
    >>>> which can be rewritten as
    >>>>
    >>>> glBegin(whatever);
    >>>> {
    >>>> glFunction1(x);
    >>>> glFunction2(y);
    >>>> ...
    >>>> }
    >>>> glEnd();
    >>>>


    >>>> Do you see anything bad about this convention?
    >>>
    >>> IMAO: it's pointless.

    >>
    >> Isn't that just a touch A, Chris? :)

    >
    > As you noticed, Bob\\\Richard, I said so myself.
    >
    >> It may not be your cup of tea, but
    >> style is a very personal thing. I'm not saying I'd necessarily do it the
    >> way he is doing it, but I can certainly see where he's coming from.

    >
    > I see what he's trying to do: I just think that it doesn't

    ....
    >>> If I wanted to do something like that,
    >>> I'd abstract those two functions into another one with a
    >>> useful name.

    >>
    >> Can you demonstrate to the OP how you would do that?


    > Replace
    >
    > glFunction1(x);
    > glFunction2(y);
    >
    > with
    >
    > aProperNameForThisModalGroup();
    >
    > defining
    >
    > static void aPropertNameForThisModalGroup()
    > {
    > glFunction1(x);
    > glFunction2(y);
    > }


    You're overcomplicating what the OP is trying to achieve. if these were
    really opengl calls then typically it might look like:

    glBegin(whatever);
    {
    glVertex(x1,y1,z1);
    glVertex(x2,y2,z2);
    glVertex(x3,y3,z3);
    .....
    };
    glEnd();

    The glBegin/glEnd calls are bracketing the data calls inbetween, but they
    belong as one unit.

    The {,} are unnecessary; just tabs are sufficient. Or BEGIN/END macros that
    do nothing.

    Creating extra functions is just extra clutter. Unless there are lots of
    calls between glBegin/glEnd but then the whole group including glBegin/glEnd
    would go into the function, and inside that function the glVertex/whatever
    calls will be indented.

    --
    Bart
     
    Bartc, Mar 26, 2008
    #10
  11. Sensei

    Chris Dollin Guest

    Bartc wrote:

    >
    > "Chris Dollin" <> wrote in message
    > news:fsd8ce$35o$...
    >> Richard Heathfield wrote:
    >>
    >>> Chris Dollin said:
    >>>
    >>>> Sensei <Sensei's e-mail is at Mac-dot-com> wrote:
    >>>>> I am thinking about the use of code blocks in order to help readability
    >>>>> of code that make use of "modal" function calls. One example is OpenGL:
    >>>>>
    >>>>> glBegin(whatever);
    >>>>> glFunction1(x);
    >>>>> glFunction2(y);
    >>>>> ...
    >>>>> glEnd();
    >>>>>
    >>>>> which can be rewritten as
    >>>>>
    >>>>> glBegin(whatever);
    >>>>> {
    >>>>> glFunction1(x);
    >>>>> glFunction2(y);
    >>>>> ...
    >>>>> }
    >>>>> glEnd();
    >>>>>

    >
    >>>>> Do you see anything bad about this convention?
    >>>>
    >>>> IMAO: it's pointless.
    >>>
    >>> Isn't that just a touch A, Chris? :)

    >>
    >> As you noticed, Bob\\\Richard, I said so myself.
    >>
    >>> It may not be your cup of tea, but
    >>> style is a very personal thing. I'm not saying I'd necessarily do it the
    >>> way he is doing it, but I can certainly see where he's coming from.

    >>
    >> I see what he's trying to do: I just think that it doesn't

    > ...
    >>>> If I wanted to do something like that,
    >>>> I'd abstract those two functions into another one with a
    >>>> useful name.
    >>>
    >>> Can you demonstrate to the OP how you would do that?

    >
    >> Replace
    >>
    >> glFunction1(x);
    >> glFunction2(y);
    >>
    >> with
    >>
    >> aProperNameForThisModalGroup();
    >>
    >> defining
    >>
    >> static void aPropertNameForThisModalGroup()
    >> {
    >> glFunction1(x);
    >> glFunction2(y);
    >> }

    >
    > You're overcomplicating what the OP is trying to achieve.


    I (obviously) don't think so.

    > if these were
    > really opengl calls then typically it might look like:
    >
    > glBegin(whatever);
    > {
    > glVertex(x1,y1,z1);
    > glVertex(x2,y2,z2);
    > glVertex(x3,y3,z3);
    > .....
    > };
    > glEnd();


    Apart from the not-necessary-for-the-examples, that's essentially what
    the OP had, so we already knew this.

    > The glBegin/glEnd calls are bracketing the data calls inbetween, but they
    > belong as one unit.


    Hence my suggestion, in the very same post, that the bracketing be
    abstracted into a function.

    > The {,} are unnecessary; just tabs are sufficient. Or BEGIN/END macros that
    > do nothing.


    I think both of those suggestions are /worse/ than just using {}.
    [I am assuming, by the way, that the clutterbraces aren't part of
    a common OpenGL style which the OP is trying to follow. If that's
    what the culture expects, then that's what the OP should use, and
    argue about it to taste.]

    > Creating extra functions is just extra clutter.


    Not when the functions can be given meaningful names, or passed as
    parameters to other functions.

    > Unless there are lots of
    > calls between glBegin/glEnd but then the whole group including glBegin/glEnd
    > would go into the function, and inside that function the glVertex/whatever
    > calls will be indented.


    If one uses the `executeModalGroup` trick, one only has to group the
    modal calls, because the modal begin-end has been encapsulated.

    --
    "The situation, it appeared, was in hand." /Excession/

    Hewlett-Packard Limited registered office: Cain Road, Bracknell,
    registered no: 690597 England Berks RG12 1HN
     
    Chris Dollin, Mar 26, 2008
    #11
  12. Sensei

    Bartc Guest

    Chris Dollin wrote:
    > Bartc wrote:


    >> "Chris Dollin" <> wrote in message
    >> news:fsd8ce$35o$...


    >>>>> Sensei <Sensei's e-mail is at Mac-dot-com> wrote:


    >>>>>>
    >>>>>> glBegin(whatever);
    >>>>>> glFunction1(x);
    >>>>>> glFunction2(y);
    >>>>>> ...
    >>>>>> glEnd();
    >>>>>>
    >>>>>> which can be rewritten as
    >>>>>>
    >>>>>> glBegin(whatever);
    >>>>>> {
    >>>>>> glFunction1(x);
    >>>>>> glFunction2(y);
    >>>>>> ...
    >>>>>> }
    >>>>>> glEnd();


    >>>>>> Do you see anything bad about this convention?


    >>> Replace
    >>>
    >>> glFunction1(x);
    >>> glFunction2(y);
    >>>
    >>> with
    >>>
    >>> aProperNameForThisModalGroup();
    >>>
    >>> defining
    >>>
    >>> static void aPropertNameForThisModalGroup()
    >>> {
    >>> glFunction1(x);
    >>> glFunction2(y);
    >>> }

    >>
    >> You're overcomplicating what the OP is trying to achieve.

    >
    > I (obviously) don't think so.


    >> glBegin(whatever);
    >> {
    >> glVertex(x1,y1,z1);
    >> glVertex(x2,y2,z2);
    >> glVertex(x3,y3,z3);
    >> .....
    >> };
    >> glEnd();

    >
    > Apart from the not-necessary-for-the-examples, that's essentially what
    > the OP had, so we already knew this.


    Well I was showing the functions were likely just supplying data.

    >> The glBegin/glEnd calls are bracketing the data calls inbetween, but
    >> they belong as one unit.

    >
    > Hence my suggestion, in the very same post, that the bracketing be
    > abstracted into a function.


    I meant the data calls belong in the same unit as the Begin/End. If
    abstracting into a separate function, then the Begin/End go there as well.

    >> The {,} are unnecessary; just tabs are sufficient. Or BEGIN/END
    >> macros that do nothing.

    >
    > I think both of those suggestions are /worse/ than just using {}.


    glBegin(whatever);
    glVertex(x1,y1,z1);
    glVertex(x2,y2,z2);
    glVertex(x3,y3,z3);
    glEnd;

    The above doesn't look so bad. But probably a little Pythonesque to a C
    programmer.

    glBegin(whatever);
    BEGIN
    glVertex(x1,y1,z1);
    glVertex(x2,y2,z2);
    glVertex(x3,y3,z3);
    END
    glEnd;

    This one you're right about.

    >> Creating extra functions is just extra clutter.

    >
    > Not when the functions can be given meaningful names, or passed as
    > parameters to other functions.


    In this example a function would most usefully wrap the whole sequence
    including Begin/End. Your suggestion would be useful if the stuff inside
    Begin..End was repeated elsewhere.

    --
    Bart
     
    Bartc, Mar 26, 2008
    #12
  13. Chris Dollin <> writes:
    > Sensei <Sensei's e-mail is at Mac-dot-com> wrote:
    >> I am thinking about the use of code blocks in order to help readability
    >> of code that make use of "modal" function calls. One example is OpenGL:
    >>
    >> glBegin(whatever);
    >> glFunction1(x);
    >> glFunction2(y);
    >> ...
    >> glEnd();
    >>
    >> which can be rewritten as
    >>
    >> glBegin(whatever);
    >> {
    >> glFunction1(x);
    >> glFunction2(y);
    >> ...
    >> }
    >> glEnd();
    >>
    >>
    >> Do you see anything bad about this convention?

    >
    > IMAO: it's pointless. If I wanted to do something like that,
    > I'd abstract those two functions into another one with a
    > useful name.


    Personally, I prefer the OP's block method to introducing a separate
    function (unless there's enough stuff going on that you'd want a
    separate function anyway). One problem with the function approach is
    that, if the code from the glBegin() call to the glEnd() call refers
    to local variables, the new function could need arbitrarily many extra
    parameters, and keeping them straight is going to be a mainenance
    headache. (If C allowed nested function definitions, this might be a
    good place to use them.)

    The issue here is that the glBegin() and glEnd() calls impose a
    logical structure on the code that's not reflected in the syntactic
    structure. Adding an artificial block, as the OP suggests, is a very
    interesting idea. (Indenting the inner statements without adding '{'
    and '}' could cause problems for tools such as automatic code
    formatters.)

    Now if glBegin returned a result that's used by the other calls, then
    the block structure would fall out naturally:

    {
    glBlob g = glBegin(whatever);
    glFunction1(g, x);
    glFunction2(g, y);
    glEnd(g);
    }

    but apparently that's not the case.

    This usage of blocks is a little unusual, but perfectly legal. If
    using blocks like this is traditional for OpenGL programming (I don't
    know whether it is or not), then by all means do it. If it isn't,
    then you're essentially creating your own coding convention. I see
    nothing wrong with that, except perhaps that readers of the code are
    going to be unfamiliar with it. It's seems obvious enough (to me,
    anyway) what you're doing; you should also document the convention.

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Mar 26, 2008
    #13
  14. Sensei

    Sensei Guest

    On 2008-03-26 08:43:29 +0100, Sensei <Sensei's e-mail is at Mac-dot-com> said:

    > Hi again! Another probably silly question. I have been reading the
    > standard but I didn't find anything about this, at a first glance. [...]



    Thanks to anyone, all your opinions are very useful to who's trying to
    improve skills!

    --

    Sensei <Sensei's e-mail is at Mac-dot-com>

    43rd Law of Computing: Anything that can go wr

    fortune: Segmentation violation
    Core dumped
     
    Sensei, Mar 26, 2008
    #14
  15. Richard Heathfield wrote:
    > Sensei <Sensei's e-mail is at Mac-dot-com> said:
    >
    >> What does the standard say about inserting code blocks? I think the
    >> following is valid C:
    >>
    >> printf("hello\n");
    >> {
    >> printf("world\n");
    >> }

    >
    > It is.
    >
    >> I am thinking about the use of code blocks in order to help readability
    >> of code that make use of "modal" function calls. One example is OpenGL:
    >>
    >> glBegin(whatever);
    >> glFunction1(x);
    >> glFunction2(y);
    >> ...
    >> glEnd();
    >>
    >> which can be rewritten as
    >>
    >> glBegin(whatever);
    >> {
    >> glFunction1(x);
    >> glFunction2(y);
    >> ...
    >> }
    >> glEnd();
    >>
    >>
    >> Do you see anything bad about this convention?

    >
    > No.


    I'm not so sure.
    glbegin(whatever);
    {
    // stuff
    }

    looks very much like a function definition, and could easily be mistaken
    for one. Indeed if one accidentally deleted the semicolon it could be
    treated as one - with amusing results.

    --
    Mark McIntyre

    CLC FAQ <http://c-faq.com/>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
     
    Mark McIntyre, Mar 26, 2008
    #15
  16. Sensei

    Ian Collins Guest

    Mark McIntyre wrote:
    >
    > I'm not so sure.
    > glbegin(whatever);
    > {
    > // stuff
    > }
    >
    > looks very much like a function definition, and could easily be mistaken
    > for one. Indeed if one accidentally deleted the semicolon it could be
    > treated as one - with amusing results.
    >

    Like failing to compile?

    I agree it does look odd.

    --
    Ian Collins.
     
    Ian Collins, Mar 26, 2008
    #16
  17. On Wed, 26 Mar 2008 08:43:29 +0100, Sensei <Sensei's e-mail is at
    Mac-dot-com> wrote:

    >Hi again! Another probably silly question. I have been reading the
    >standard but I didn't find anything about this, at a first glance.
    >
    >What does the standard say about inserting code blocks? I think the
    >following is valid C:
    >
    >printf("hello\n");
    >{
    > printf("world\n");
    >}
    >
    >I am thinking about the use of code blocks in order to help readability
    >of code that make use of "modal" function calls. One example is OpenGL:
    >
    >glBegin(whatever);
    >glFunction1(x);
    >glFunction2(y);
    >...
    >glEnd();
    >
    >which can be rewritten as
    >
    >glBegin(whatever);
    >{
    > glFunction1(x);
    > glFunction2(y);
    > ...
    >}
    >glEnd();


    As noted elsewhere this can be mistaken for a function definition
    and anyways it looks strange. If you want to delimit this why
    not move glBegin and glEnd inside the brackets. Thus:

    /* This block handles the blah blah action */
    {
    glBegin(whatever);
    glFunction1(x);
    glFunction2(y);
    ...
    glEnd();
    }


    Richard Harter,
    http://home.tiac.net/~cri, http://www.varinoma.com
    Save the Earth now!!
    It's the only planet with chocolate.
     
    Richard Harter, Mar 27, 2008
    #17
  18. Mark McIntyre said:
    > Richard Heathfield wrote:
    >> Sensei <Sensei's e-mail is at Mac-dot-com> said:


    <snip>

    >>> Do you see anything bad about this convention?

    >>
    >> No.

    >
    > I'm not so sure.
    > glbegin(whatever);
    > {
    > // stuff
    > }
    >
    > looks very much like a function definition,


    No, it doesn't. For one thing, it doesn't have a return type. For another,
    it doesn't have type names in the parameter list. For a third, it has a
    semicolon in a crucial place. For a fourth, when it is properly indented
    it is blindingly obvious that it's code, because C doesn't have nested
    functions.

    > and could easily be mistaken for one.


    Yes, if you squiggle up your eyes just so, you can sometimes trick them
    into seeing the corner of your room look as if the walls recede from the
    corner, going away from you into the distance. But it's a hard illusion to
    maintain, and you can't do it for very long, and in the meantime you can
    lean on the wall anyway.

    > Indeed if one accidentally deleted the semicolon it could be
    > treated as one - with amusing results.


    It seems you are easily amused. :)

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Mar 27, 2008
    #18
  19. Sensei

    Chris Dollin Guest

    Keith Thompson wrote:

    > Personally, I prefer the OP's block method to introducing a separate
    > function (unless there's enough stuff going on that you'd want a
    > separate function anyway). One problem with the function approach is
    > that, if the code from the glBegin() call to the glEnd() call refers
    > to local variables, the new function could need arbitrarily many extra
    > parameters, and keeping them straight is going to be a mainenance
    > headache. (If C allowed nested function definitions, this might be a
    > good place to use them.)


    Yes: when I was more relaxed (ie on my way home) I realised part of my
    head believed that C functions had polymorphic types. Without them my
    "encapsulate begin-end" trick is substantially less useful ...

    --
    "Its flagships were suns, its smallest vessels, /The City and the Stars/
    planets."

    Hewlett-Packard Limited registered office: Cain Road, Bracknell,
    registered no: 690597 England Berks RG12 1HN
     
    Chris Dollin, Mar 27, 2008
    #19
  20. On 26 Mar, 10:56, Antoninus Twink <> wrote:
    > On 26 Mar 2008 at  9:04, Chris Dollin wrote:
    > > Sensei <Sensei's e-mail is at Mac-dot-com> wrote:


    > >> I am thinking about the use of code blocks in order to help readability
    > >> of code that make use of "modal" function calls. One example is OpenGL:

    >
    > >> glBegin(whatever);
    > >> glFunction1(x);
    > >> glFunction2(y);
    > >> ...
    > >> glEnd();

    >
    > >> which can be rewritten as

    >
    > >> glBegin(whatever);
    > >> {
    > >>    glFunction1(x);
    > >>    glFunction2(y);
    > >>    ...
    > >> }
    > >> glEnd();

    >
    > >> Do you see anything bad about this convention?

    >
    > > IMAO: it's pointless. If I wanted to do something like that,
    > > I'd abstract those two functions into another one with a
    > > useful name.

    >
    > You mean, into a macro, to avoid the extra function call overhead


    this is premature optimisation. There are all sorts of problems
    with macros. Including lack of type safety (it doesn't check the type
    of parameters), file scope (if you declare a macro inside a function
    it actually persists until explicitly undefined or the end of file),
    textual substitution of parameters and multiple evaluation
    of parameters.

    consider
    #define MUL(A, B) A * B
    and this invocation
    MUL(2+2, 3+3)

    you might expect this to evaluate to 4*6
    but it actually expands to
    2+2 * 3+3

    which evaluates as
    2 + (2 * 3) + 3

    this can be "fixed" with this
    #define MUL(A, B) ((A) * (B))

    Now consider this
    a = 2;
    b = MUL (a++, a++);

    again this may not be what is wanted:

    b = a++ * a++;


    oh, and the syntax is ugly.


    I can't believe I responded to the twink...
    But it's the first time I've seen it post something technical.


    --
    Nick Keighley

    oh, that's too simple to test...
     
    Nick Keighley, Mar 27, 2008
    #20
    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. Arjen
    Replies:
    3
    Views:
    471
    Scott Allen
    Feb 27, 2005
  2. Bob Nelson

    doubt about doubt

    Bob Nelson, Jul 28, 2006, in forum: C Programming
    Replies:
    11
    Views:
    659
  3. matt
    Replies:
    1
    Views:
    296
    George Ogata
    Aug 6, 2004
  4. Steven Taylor
    Replies:
    9
    Views:
    280
    Brian Candler
    Apr 27, 2009
  5. Replies:
    0
    Views:
    592
Loading...

Share This Page