Simple doubt about blocks

[Sensei]

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)

 

[Richard Heathfield]

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.

 

[santosh]

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>

 

[Chris Dollin]

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.

 

[Richard Heathfield]

Chris Dollin said:

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?

 

[Chris Dollin]

Chris Dollin said:


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".

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

with

executeModelGroup( aProperNameForThisModelGroup );

Decorate with parameters as necessary.

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

 

[Antoninus Twink]

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]

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.

 

[Chris Dollin]

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.

 

[Bartc]

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


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

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.

 

[Chris Dollin]

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.

 

[Bartc]

Bartc wrote:

I (obviously) don't think so.

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.

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.

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.

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.

 

[Keith Thompson]

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.

 

[Sensei]

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

 

[Mark McIntyre]

It is.


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.

 

[Ian Collins]

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.

 

[Richard Harter]

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, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

 

[Richard Heathfield]

Mark McIntyre said:

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.

 

[Chris Dollin]

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

 

[Nick Keighley]

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.