Board index » cppbuilder » Re: A comma at the end of a macro

Re: A comma at the end of a macro


2008-01-24 03:26:26 PM
cppbuilder35
You're right. Sorry. I got confused, I was thinking of extra semicolons
after functions I think. The Borland compiler still accepts those too, but I
guess they don't really come in to play as often with macros.
Duh,
Jason
"Gillmer J. Derge [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
Jason Cipriani wrote:
>Unless you try to compile your code with a strict compiler and it fails
>because "};" isn't actually valid C++ in that context. Many compilers
>(such as the Borland one), sadly, still accept it for backwards
>compatibility.

There's a good reason why compilers accept "};", and it isn't backward
compatibility. It's valid code. From the standard:

statement:
expression-statement
compound-statement
...

expression-statement:
expression_opt ;

compound-statement:
{ statement-seq_opt }

The _opt items are optional, thus the following is a valid series of C++
statements.

{} ; ; ; {{} {} ; {}} ; {} {;;{}{}};{}

--
Gillmer J. Derge [TeamB]
 
 

Re:Re: A comma at the end of a macro

"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
Why must M1 be a macro and not an inline function?
It is a C-project. Though there is a possibility to write inline functions
using a corresponding #pragma statement however historically due to more old
used version of a compiler macros are intencivily used. I also prefer to
write inline functions.
Quote

>#define M2( a1, a2, ...) \
>if ( a2 == SOME_CONSTANT ) \
>f( a1, a2. __VA_ARGS__ ); \
>else \
>{ M1(); }

Why must M2 be a macro and not just a function taking variable args?

Checking of parameters must be done before calling the function because the
calling mechanism is time consuming. The processor (mainframe) changes its
address mode. stores all registers and other information.
Quote
>In some module there is the following code
>
>if ( 1 )
>M2( a1, a2, a3, a4 );
>else
>{}

The earlier suggestion was to always wrap your "if" and "else" body in
curly braces, even if it's just a single line. Not only is it more
readable, but it's far less error prone, and the code is more
_regular_ in shape.

The code exists already without using curly braces. It is simply to change
the macro then change all places in the code where there is access to the
macro.
Vladimir Grigoriev
 

Re:Re: A comma at the end of a macro

"Bob Gonder" < XXXX@XXXXX.COM >wrote in message
Quote
If you use braces always, it will always be right.
I always use braces so I don't have to think about it.


However not all programmers behave as you! :) The code where the macros is
called is already written.
Vladimir Grigoriev
 

{smallsort}

Re:Re: A comma at the end of a macro

"Gillmer J. Derge [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
Bob Gonder wrote:
>//I would also add braces around this

You aren't the first person in this thread to suggest this, but I
don't understand why this is being offered as a solution. It's a
stylistic choice, and although I also try to follow that style, I
don't expect everyone who uses my code to do the same.
It's more than style, though. Anytime you have something like this:
if (condition)
MACRO_EXPANSION(arg);
else
// something else
The code is subject to bugs if the macro expansion happens to change.
For example what if the macro is:
#define MACRO_EXPANSION(OBJ_PTR) \
std::cout << *OBJ_PTR << std::endl
Then a month later it is found that OBJ_PTR may be null, so the macro
is modified to:
#define MACRO_EXPANSION(OBJ_PTR) \
if (OBJ_PTR) \
std::cout << *OBJ_PTR << std::endl
Now the earlier code expands to this:
if (condition)
if (ptr)
std::cout << *ptr << std::endl;
else
// something else
And suddenly the entire meaning of the else clause changes, attached
to the macro's if instead of the one to which it was intended.
Perhaps you might argue that the bug is in the macro, but that doesn't
affect the argument I'm making. Curly braces around the if body would
have rendered it harmless.
C++'s idea of "optional" braces, only necessary for compound
statements is dangerous in cases like this, and it's a very good
programming practice to adopt the rule that for "if" and "else" bodies
you must always use braces to enclose the body. It's an easy rule to
explain, and makes code more consistent in its shape.
It is a problem to suggest changing your existing code. Agreed. It's
not a realistic solution to change existing code everywhere to not do
something dangerous, if it is already coded that way. However, moving
forward with future code, it's wise to always brace-enclose the code.
Always.
Quote
How would you feel if you bought a compiler that only worked with the
author's choice of indentation and whitespace allocation? I'd feel
like the author was an idiot and like I got ripped off.
That's a different question though. That kind of code change doesn't
affect runtime behavior in any way. And so you are right to ridicule
such a suggestion.
(Unless it's for Python or a Fortran compiler, where indentation
matters...)
Quote
If you're writing a statement-like macro, take the time to wrap it
with something like the "do { ... } while (0)" hack. It isn't hard,
it doesn't change your code's performance, and it makes it just work,
no matter how you or anyone else decide to format your code.
I agree, write macros correctly. But also, write if's safely.
--
Chris (TeamB);
 

Re:Re: A comma at the end of a macro

Chris Uzdavinis (TeamB) wrote:
Quote
And suddenly the entire meaning of the else clause changes, attached
to the macro's if instead of the one to which it was intended.
Perhaps you might argue that the bug is in the macro, but that doesn't
affect the argument I'm making. Curly braces around the if body would
have rendered it harmless.
Yes, I would argue that the bug is in the macro, and I think it does
affect the argument you're making. do/while around the macro would have
rendered it harmless. If that works to support your point, why doesn't
it work for me too?
Quote
I agree, write macros correctly. But also, write if's safely.
If that's the point, then I agree completely. My objection is to the
idea that writing if's safely is the solution to a bad macro. It's a
good idea in general, but the solution to a bad macro is to fix it and
turn it into a good macro.
I see these as two completely unrelated suggestions that happen to have
a coincidental synergy in a few situations. Putting braces around your
if's doesn't mean you should stop worrying about whether your macros are
written properly.
--
Gillmer J. Derge [TeamB]
 

Re:Re: A comma at the end of a macro

"Gillmer J. Derge [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
Chris Uzdavinis (TeamB) wrote:
>And suddenly the entire meaning of the else clause changes, attached
>to the macro's if instead of the one to which it was intended.
>Perhaps you might argue that the bug is in the macro, but that doesn't
>affect the argument I'm making. Curly braces around the if body would
>have rendered it harmless.

Yes, I would argue that the bug is in the macro, and I think it does
affect the argument you're making. do/while around the macro would have
rendered it harmless. If that works to support your point, why doesn't it
work for me too?

>I agree, write macros correctly. But also, write if's safely.

If that's the point, then I agree completely. My objection is to the idea
that writing if's safely is the solution to a bad macro. It's a good idea
in general, but the solution to a bad macro is to fix it and turn it into
a good macro.

I see these as two completely unrelated suggestions that happen to have a
coincidental synergy in a few situations. Putting braces around your if's
doesn't mean you should stop worrying about whether your macros are
written properly.
I would prefer to avoid macros completely. Why is this
one necessary?
 

Re:Re: A comma at the end of a macro

"Duane Hebert" < XXXX@XXXXX.COM >wrote in message
Quote

I would prefer to avoid macros completely. Why is this
one necessary?

Because they existed before we started to write programs.:)
Vladimir Grigoriev
 

Re:Re: A comma at the end of a macro

Gillmer J. Derge [TeamB] wrote:
Quote
good idea in general, but the solution to a bad macro is to fix it and
turn it into a good macro.

The only good macro is a dead macro <g>
 

Re:Re: A comma at the end of a macro

"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
The code is subject to bugs if the macro expansion happens to change.
No. It's the author's responsibility to ensure that if their macro was a
single statement before, then it stays able to be treated that way. It's not
the person using the macro's responsibility to check that kind of stuff. If
you change a single-statement macro to be multiple statements and break
everybody's code, then you should expect a lot of angry emails.
 

Re:Re: A comma at the end of a macro

Alex Bakaev [TeamB] wrote:
Quote
The only good macro is a dead macro <g>
What about assert?
--
Gillmer J. Derge [TeamB]
 

Re:Re: A comma at the end of a macro

Gillmer J. Derge [TeamB] wrote:
Quote
What about assert?

It's a killer.
 

Re:Re: A comma at the end of a macro

Jason Cipriani wrote:
Quote
No. It's the author's responsibility to ensure that if their macro was a
Defensive programming is never a bad idea. Always using curly braces is
one of the cheapest sources of defensive programming.
 

Re:Re: A comma at the end of a macro

"Vladimir Grigoriev" < XXXX@XXXXX.COM >wrote in message
Quote

"Duane Hebert" < XXXX@XXXXX.COM >wrote in message
news:4798aa52$ XXXX@XXXXX.COM ...
>
>I would prefer to avoid macros completely. Why is this
>one necessary?
>

Because they existed before we started to write programs.:)
Yeah, We've been saddled with some old C code a few times now
that couldn't be rewritten and had such constructs.
FWIW it has all been rewritten now since we found it more
expedient to do so than maintaining as is.
 

Re:Re: A comma at the end of a macro

"Gillmer J. Derge [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
Yes, I would argue that the bug is in the macro, and I think it does
affect the argument you're making. do/while around the macro would
have rendered it harmless. If that works to support your point, why
doesn't it work for me too?
I am advocating for doing both. As a user of a macro, if you can
isolate your code from it you're better off. As a producer of a
macro, you owe it to your users to write it well.
...
Quote
If that's the point, then I agree completely. My objection is to the
idea that writing if's safely is the solution to a bad macro. It's a
good idea in general, but the solution to a bad macro is to fix it and
turn it into a good macro.
We are in agreement.
My concern was that a valid proposal for writing better code was being
shot down. Yes, it isn't THE solution to the problem presented, but
that's no reason why it shoudln't be done anyway.
Quote
I see these as two completely unrelated suggestions that happen to
have a coincidental synergy in a few situations. Putting braces
around your if's doesn't mean you should stop worrying about whether
your macros are written properly.
Exactly.
--
Chris (TeamB);
 

Re:Re: A comma at the end of a macro

Well, since we're talking about it... I've found some, say, "creative" uses
for them though that have really come in handy. I frequently use macros to
define the entire declaration and definition of an exception class,
accepting the base class name and new class name as parameters. It made
creating lots of specific types of exceptions really easy:
EXCEPTION_CLASS(BaseException, DerivedException);
EXCEPTION_CLASS(BaseException, AnotherException);
EXCEPTION_CLASS(AnotherException, TotallyCrazyException);
I also remember using them for this weird code optimization one time;
something like:
void somefunction (bool option1, bool option2) {
if (option1) {
if (option2)
SOME_MACRO(true, true);
else
SOME_MACRO(true, false);
} else {
if (option2)
SOME_MACRO(false, true);
else
SOME_MACRO(false, false);
}
}
Where SOME_MACRO has the function code in it, and that takes advantage of
the compiler optimizing away constant if conditions (the function code
itself had tons of branches based on the options, in this case the macro let
me optimize the branches away but also only have a single copy of the code,
which was being modified pretty frequently -- it was pretty ugly [and the
actual program had 5 bool parameters, so 32 combinations although only like
28 or something were actually valid] but it would have been worse without
the macro).
Jason
"Vladimir Grigoriev" < XXXX@XXXXX.COM >wrote in message
Quote

"Duane Hebert" < XXXX@XXXXX.COM >wrote in message
news:4798aa52$ XXXX@XXXXX.COM ...
>
>I would prefer to avoid macros completely. Why is this
>one necessary?
>

Because they existed before we started to write programs.:)

Vladimir Grigoriev