"Paul Mensonides" <pmenso57@comcast.net> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
It's more convenient in exactly one way only: a particular *editor* has trouble properly automatically formatting code.
No, I pointed out several other practical considerations, not least of which is that if you make a mistake with the other convention, your compiler is unlikely to tell you about it and your code will be nonportable.
Such a mistake is the result of a fundamentally flawed viewpoint.
Wow, that's pretty strong language. I've made the mistake, and I just don't see how my viewpoint is "fundamentally flawed." I don't pretend macro invocations are function calls. I always view them as code generators. I'm just not always sure which code they're generating, and -- yes -- sometimes I write fast and the keystrokes `) ; Ret' just flow off my fingers without my brain having a chance to intervene.
One which I don't think we should accommodate. Worst case scenario is that someone makes the mistake and it has to be trivially fixed in a port. Fixing a "semicolon not allowed here" error is hardly difficult.
It depends whether you're the person at liberty to change the code. It sounds like you're saying: - Some naive users think macros are the same as functions - That causes them to make mistakes - Thererefore we should design all macros to forbid a trailing semicolon in order to discourage that misconception - And the following are non factors - That the rest of users have no illusions about the role of macros - How much easier it makes things when the macro requires the semicolon - That requiring the semicolon can keep a category of errors from creeping into code In other words, everything else in service of wiping out some people's silly misconceptions about what macros are. Have I got that right? For my part, I think my priorities are exactly inverted from yours.
The last thing we should be at all concerned about is automatic formatting in some editor.
Convenience, usability, and the chance of not making a trivial unintentional error are important factors in the design of any component.
Convenience and usability from the point of view of other source code, not how that source code is written.
I _thought_ for a minute I understood what you meant by "from the point of view of other source code," but now I'm less sure. Seems to me "other source code" doesn't care about convenience and usability; only its author does.
macro only accomplishes *part* of its function--it only generates *part* of the code.
Sorry, _what_ means the macro only accomplishes *part* of its function?
When a macro can be designed to encapsulate a standalone syntactic entity but doesn't. E.g.
#define MACRO struct xyz { }
MACRO;
...is no different from...
#define MACRO struct xyz {
MACRO };
Well, of course it's different.
It starts it, but it doesn't finish it.
Ahem. From the C++ standard grammar summary: class-specifier: class-head { member-specification(opt) }
As I mention below, sometimes it isn't possible, but this isn't one of those cases.
It sure is.
Sometimes that's necessary; this isn't one of those cases. The viewpoint that must prevail is that macros are code writers.
That is my viewpoint, for sure. I'm also in favor of making them as easy to use and as foolproof as possible.
Making them foolproof can't be done without a perspective shift from the user,
No, that does an end run around the goal: at that point the user is no longer a fool. Disabusing people of foolishness is very, very hard, so when providing a library I adopt a "policy of engagement:" I try to design the library based on sound principles, but in such a way that the user can experience success before shedding his foolishness. I hope that one day the sound principles will rub off and begin to enlighten.
and adding or elliding the semicolon doesn't make it easier or harder to use.
I am only becoming more convinced to the contrary.
It just makes it look more like a function call--to some editors as well as users.
It doesn't "just" do that.
The problem that I have is not so much with catering to editors (though I am against that in principle), but with catering to an incorrect viewpoint. The harm in doing so far outweighs extraneous issues like source code formatting over time.
If that was my motivation, I'd agree. But in fact requiring the semicolon makes it easier and less error-prone even for people with a correct viewpoint on the role of macros. -- Dave Abrahams Boost Consulting www.boost-consulting.com