Hi all, Not having extra semicolons is one of the strongest arguments against incuding a trailing semicolon into a statement-generating macro. Can anybody explain why having an extra semicolon is considered a potential problem by some compilers? Isn't null as good as any other number? Shouldn't an empty statement be considered as good as any other statement? Regards, Arkadiy
Arkadiy Vertleyb writes:
Hi all,
Not having extra semicolons is one of the strongest arguments against incuding a trailing semicolon into a statement-generating macro. Can anybody explain why having an extra semicolon is considered a potential problem by some compilers? Isn't null as good as any other number? Shouldn't an empty statement be considered as good as any other statement?
Ths issue is IIRC and AFAIK macros that are used outside of any statement blocks, i.e. the thing David Abrahams suggested that spawned this whole thread. Something like a macro that declares or defines a function: #define MAKEFOO inline void foo () { ... } and then simply used as: (... other inline functions, for example ...) MAKEFOO; The point is that after macro expansion, that semicolon I put in after the macro invocation isn't valid, because I'm not allowed to have a null statement (or any other kind of statement) at this point in the file. The presence or absence of that semicolon is what the fuss has been about. :-) ---------------------------------------------------------------------- Dave Steffen, Ph.D. "There are two ways to write error-free Software Engineer IV programs; only the third one works." Numerica Corporation ph (970) 419-8343 x27 "Pie are not square. Pie are round. fax (970) 223-6797 Cornbread are square" dgsteffen@numerica.us ... anon (usenet) ___________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.
"Dave Steffen" <dgsteffen@numerica.us> wrote
Arkadiy Vertleyb writes:
Hi all,
Not having extra semicolons is one of the strongest arguments against incuding a trailing semicolon into a statement-generating macro. Can anybody explain why having an extra semicolon is considered a potential problem by some compilers? Isn't null as good as any other number? Shouldn't an empty statement be considered as good as any other statement?
Ths issue is IIRC and AFAIK macros that are used outside of any statement blocks, i.e. the thing David Abrahams suggested that spawned this whole thread. Something like a macro that declares or defines a function:
#define MAKEFOO inline void foo () { ... }
and then simply used as:
(... other inline functions, for example ...) MAKEFOO;
The point is that after macro expansion, that semicolon I put in after the macro invocation isn't valid, because I'm not allowed to have a null statement (or any other kind of statement) at this point in the file.
The presence or absence of that semicolon is what the fuss has been about. :-)
I tought it was about placing a trailing semicolon inside or outside a macro definition, something like: #define MACRO struct x{} versus #define MACRO struct x{}; So that it is used MACRO(); // works nice with editors or MACRO() // more consistent My point is that it would be possible to have both possibilities if empty statements were allowd. The question was why are they not (by some compilers)? Regards, Arkadiy
Arkadiy Vertleyb writes:
"Dave Steffen" <dgsteffen@numerica.us> wrote
Ths issue is IIRC and AFAIK macros that are used outside of any statement blocks, i.e. the thing David Abrahams suggested that spawned this whole thread. Something like a macro that declares or defines a function:
#define MAKEFOO inline void foo () { ... }
and then simply used as:
(... other inline functions, for example ...) MAKEFOO;
The point is that after macro expansion, that semicolon I put in after the macro invocation isn't valid, because I'm not allowed to have a null statement (or any other kind of statement) at this point in the file.
The presence or absence of that semicolon is what the fuss has been about. :-)
I tought it was about placing a trailing semicolon inside or outside a macro definition, something like:
#define MACRO struct x{}
versus
#define MACRO struct x{};
Ok, yes, that's another side of the issue. I should have been clearer. "The issue is" (take 2 :-) that there are some places where semicolons are required, and some where they are prohibited. Given the existence of macros, A) should macros intended for use in places where a trailing semicolon is mandated, include that semicolon in their definitions? B) should macros intended for use in place where trailing macros are prohibited, take steps to allow a trailing semicolon because some users of the macro would like to put one there?
My point is that it would be possible to have both possibilities if empty statements were allowd. The question was why are they not (by some compilers)?
... and what I attempted to say (and didn't very well) is that in places where null statements are allowed, yes, you're correct; the macro could include its own semicolon, and people who want add their own are allowed to.... ... with a few exceptions. As has been pointed out, if (something) MACRO_INVOCATION(); else ... is sensitive to how many semicolons end up at the end of the macro expansion. Whereas, in the case of function-defining macros and other odd things, you can't have a semicolon at all, because null statements aren't allowed there. The question of why anyone would add a semicolon after such a macro is sort of what the hubbub is about; some people like me think it looks natural, others like Paul think it's an abomination. :-) ---------------------------------------------------------------------- Dave Steffen, Ph.D. "There are two ways to write error-free Software Engineer IV programs; only the third one works." Numerica Corporation ph (970) 419-8343 x27 "Pie are not square. Pie are round. fax (970) 223-6797 Cornbread are square" dgsteffen@numerica.us ... anon (usenet) ___________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Dave Steffen
... and what I attempted to say (and didn't very well) is that in places where null statements are allowed, yes, you're correct; the macro could include its own semicolon, and people who want add their own are allowed to....
... with a few exceptions. As has been pointed out,
if (something) MACRO_INVOCATION(); else ...
Incidentally, this should automatically be: if (something) { MACRO_INVOCATION(); // semicolon argument aside } else ... Because if the macro expands to statement, it could just as easily expand to a series of statements. Regards, Paul Mensonides
Paul Mensonides wrote:
Incidentally, this should automatically be:
if (something) { MACRO_INVOCATION(); // semicolon argument aside } else ...
Because if the macro expands to statement, it could just as easily expand to a series of statements.
But doesn't everybody wrap those in do-while loops? I.e., #define FOO do { bar; baz; } while (false) -- Jason McCarty <bclg@iup.edu>
Jason McCarty writes:
Paul Mensonides wrote:
Incidentally, this should automatically be:
if (something) { MACRO_INVOCATION(); // semicolon argument aside } else ...
Because if the macro expands to statement, it could just as easily expand to a series of statements.
But doesn't everybody wrap those in do-while loops? I.e., #define FOO do { bar; baz; } while (false)
That's only for macros which are used like function calls. Macros that, for example, define families of related functions, can't use that trick. There _is_ a trick that can be used if you want those kind of macros to be followed by a semicolon; all the recent heat around this topic amounts to whether or not that should be done. ---------------------------------------------------------------------- Dave Steffen, Ph.D. "There are two ways to write error-free Software Engineer IV programs; only the third one works." Numerica Corporation ph (970) 419-8343 x27 "Pie are not square. Pie are round. fax (970) 223-6797 Cornbread are square" dgsteffen@numerica.us ... anon (usenet) ___________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jason McCarty
Paul Mensonides wrote:
Incidentally, this should automatically be:
if (something) { MACRO_INVOCATION(); // semicolon argument aside } else ...
Because if the macro expands to statement, it could just as easily expand to a series of statements.
But doesn't everybody wrap those in do-while loops? I.e., #define FOO do { bar; baz; } while (false)
I don't. I think that it increases the complexity of the macro for the only purpose of making the macro use look like its a regular syntactic element--which I don't think is a good idea, and therefore don't do it. Regards, Paul Mensonides
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
My point is that it would be possible to have both possibilities if empty statements were allowd.
They are allowed.
The question was why are they not (by some compilers)?
Empty declarations are not allowed by the language specification, and only some compilers enforce it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Dave Steffen" <dgsteffen@numerica.us> wrote
Arkadiy Vertleyb writes:
Hi all,
Not having extra semicolons is one of the strongest arguments against incuding a trailing semicolon into a statement-generating macro. Can anybody explain why having an extra semicolon is considered a potential problem by some compilers? Isn't null as good as any other number? Shouldn't an empty statement be considered as good as any other statement?
Ths issue is IIRC and AFAIK macros that are used outside of any statement blocks, i.e. the thing David Abrahams suggested that spawned this whole thread. Something like a macro that declares or defines a function:
#define MAKEFOO inline void foo () { ... }
and then simply used as:
(... other inline functions, for example ...) MAKEFOO;
FWIW This compiles fine in VC7.1 . AFAIK there is no C++ rule banning an empty statement in any scope( including namespace scope) where a statement is otherwise allowed. Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Dave Steffen" <dgsteffen@numerica.us> wrote
Arkadiy Vertleyb writes:
Hi all,
Not having extra semicolons is one of the strongest arguments against incuding a trailing semicolon into a statement-generating macro. Can anybody explain why having an extra semicolon is considered a potential problem by some compilers? Isn't null as good as any other number? Shouldn't an empty statement be considered as good as any other statement?
Ths issue is IIRC and AFAIK macros that are used outside of any statement blocks, i.e. the thing David Abrahams suggested that spawned this whole thread. Something like a macro that declares or defines a function:
#define MAKEFOO inline void foo () { ... }
and then simply used as:
(... other inline functions, for example ...) MAKEFOO;
FWIW This compiles fine in VC7.1 . AFAIK there is no C++ rule banning an empty statement in any scope( including namespace scope) where a statement is otherwise allowed.
But that's just it: statements aren't allowed at namespace scope. Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1 Copyright 1988-2003 Comeau Computing. All rights reserved. MODE:strict errors C++ "ComeauTest.c", line 2: error: extra ";" ignored, In C: A function definition does not end with a semicolon In C++: A function definition, extern "C" or namespace, does not end with a semicolon MAKEFOO; ^ 1 error detected in the compilation of "ComeauTest.c". In strict mode, with -tused, Compile failed -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
FWIW This compiles fine in VC7.1 . AFAIK there is no C++ rule banning an empty statement in any scope( including namespace scope) where a statement is otherwise allowed.
But that's just it: statements aren't allowed at namespace scope.
Thats not correct. A declaration-statement is a statement. However I assume what you are trying to say is ; if statements allowed at namespace scope cannot be empty then by deduction semicolons representing empty statements are not permitted at namespace scope. Apologies for the misleading comment. Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
FWIW This compiles fine in VC7.1 . AFAIK there is no C++ rule banning an empty statement in any scope( including namespace scope) where a statement is otherwise allowed.
But that's just it: statements aren't allowed at namespace scope.
Thats not correct. A declaration-statement is a statement.
However I assume what you are trying to say is ; if statements allowed at namespace scope cannot be empty then by deduction semicolons representing empty statements are not permitted at namespace scope.
Oops sorry for trying to put words in someone elses mouth. Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
FWIW This compiles fine in VC7.1 . AFAIK there is no C++ rule banning an empty statement in any scope( including namespace scope) where a statement is otherwise allowed.
But that's just it: statements aren't allowed at namespace scope.
Thats not correct. A declaration-statement is a statement.
However I assume what you are trying to say is ; if statements allowed at namespace scope cannot be empty then by deduction semicolons representing empty statements are not permitted at namespace scope.
Oops sorry for trying to put words in someone elses mouth.
I didn't mind. I don't know what I was trying to say. I obviously don't remember how the grammar works; I thought statements strictly appeared at function scope. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Oops sorry for trying to put words in someone elses mouth.
I didn't mind. I don't know what I was trying to say. I obviously don't remember how the grammar works; I thought statements strictly appeared at function scope.
FWIW I wrote a web page once upon a time to help me through the grammar. Its available here: http://www.servocomm.freeserve.co.uk/Cpp/grammar/index.html Alphabet list at top brings up required alphabetical non-terminal group in left pane. Click on particular non-terminal to bring up associated production in right pane. Clicking any non-terminal left or right pane moves its production into view in right hand pane. regards Andy Little
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ufyubyn3x.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
FWIW This compiles fine in VC7.1 . AFAIK there is no C++ rule banning an empty statement in any scope( including namespace scope) where a statement is otherwise allowed.
But that's just it: statements aren't allowed at namespace scope.
Thats not correct. A declaration-statement is a statement.
However I assume what you are trying to say is ; if statements allowed at namespace scope cannot be empty then by deduction semicolons representing empty statements are not permitted at namespace scope.
Oops sorry for trying to put words in someone elses mouth.
I didn't mind. I don't know what I was trying to say. I obviously don't remember how the grammar works; I thought statements strictly appeared at function scope.
Actually I now think that you are correct and I am wrong , because statements only appear on the rhs of the production within expressions. Therefore the statement suffix on declaration-statement indicates a declaration within an expression,whereas outside it is simply a declaration. Sorry for the confusion. Andy Little
participants (6)
-
Andy Little -
Arkadiy Vertleyb -
Dave Steffen -
David Abrahams -
Jason McCarty -
Paul Mensonides