«

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

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) <kst->
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

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

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

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.

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

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

On 26 Mar, 10:56, Antoninus Twink <nos...@nospam.invalid> 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...