From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-15 04:28:18
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] 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. 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.
> > 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.
> > 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 };
It starts it, but it doesn't finish it. As I mention below, sometimes it isn't
possible, but this isn't one of those cases.
> > 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,
and adding or elliding the semicolon doesn't make it easier or harder to use.
It just makes it look more like a function call--to some editors as well as
users. 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.
Regards,
Paul Mensonides