
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Arkadiy Vertleyb
and by automatic formatting of some editors that many people use (but many people don't).
I don't think it is correct to say that many C++ programmers don't use Visual C++, for example. It was already mentioned on this list at some point that most people do, maybe as a secondary compiler. And, In Visual Studio it is quite annoying to deal with constructs that do not adhere to the C++ syntax.
BTW, I use the VC++ IDE, but I rarely compile anything with VC++. I use it mainly for project management and editing. You're right, it does a horrible job at syntax highlighting and parentheses matching, but I use it precisely because it does not automatically indent code in a way that I can't correct without it constantly changing it back.
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.
And this viewpoint is that a macro invocation is a function call?
No, that a macro invocation is a kind of unit of work similar to a function call. For example, #define max(a, b) ((a) < (b) ? (b) : (a)) ... max(x, y) ... Most programmers view this invocation as a macro that returns the greater of two arguments. That viewpoint is wrong, and is what leads, in this scenario, to multiple evaluation problems. What the macro does is expand to the expression ((a) ... ).
I am not sure about Dave's case, but I am more concerned about the case when a macro expands into a number of template specializations. So, when I am saying:
REGISTER_TYPE(x)
it is actually:
GENERATE_RELEVANT_TEMPLATE_SPECIALIZATIONS_FOR_TYPE(x)
Do you think requiring a semicolon would be incorrect here?
For example: #define MAKE() \ struct abc { }; \ struct xyz { } \ /**/ MAKE(); I find adding the first semicolon after 'abc', but not adding the second semicolon after 'xyz' to be an abomination. I find that worse that the case of single struct definition (e.g.) because now the macro definition is inconsistant within itself. Despite that, I still think that in the single definition case the macro should include the trailing semicolon--unless you intentionally want to allow users to define variables (or types through 'typedef MACRO() x;') Regards, Paul Mensonides