-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
Any kind of tool that does analysis on C or C++ code, even if only at a syntactic level, has to be able to see through macro expansion. This is a
Nope. See below.
Anything less just means it is an robust, but generic, editor, rather than a robust C++ editor.
It is impossible. There is no way for an editor to know the manifest constants, predefined or otherwise, on which the preprocessor will act to determine which code will be in effect when compiling. Thus, the editor cannot determine the definition of the macro with any accuracy or consistency, so it cannot ascertain the syntactic effect of the macro invocation.
The editor can't automatically determine command line arguments or macros predefined by the compiler (or compiler) to be used, that's true. Those would have to be supplied, but the rest can be done. Some environments already do it with varying degrees of success for other reasons. I have seen it done where it is fast enough. I've yet to see it done where it was good enough though, but I do think it's possible.
There are but two choices for the editor: ignore the macro invocation and indent based upon the code preceding it, or treat the macro as an expression and not a statement. Well, I suppose there's a third choice, but that entails keeping a database of user overrides. However, that is untenable as changes introduced into a VCS can completely disconnect the override data from the text of the file.
The third option is to use an explicit workaround in the code that uses the macro.
Thus, by your definition, there cannot be a "robust C++ editor" unless we eliminate the preprocessor.
No, there can be, it's just that some of it has to come from a configuration file.
I have a serious problem catering to people that don't care also. I don't have a problem with making them work a little as a result of the apathy.
Life's tough that way sometimes. Seriously, absolute purity in any endeavor usually serves no goal but to alienate most.
This is a case where purity, in this small way, can be achieved without breaking code on a bunch of compilers. The syntax of C or C++ is dynamic, because of the preprocessor, and that's just the way it is. An editor that cannot handle that is deficient when macros come into play. Such editors may or may not be worth fixing, but as they are now, that is a deficiency. This deficiency can be worked around in two places: 1) in the library, thus subjecting all users regardless of the editor they use to the workaround, or 2) in the user code (or a user library) of those users that use these particular editors. I don't have a problem with workarounds--well, I do, but I realize that they are a necessary evil--but I do have a potential problem with the location of some workarounds and how explicit (or not) that they are.
This case isn't that extreme, I'll grant. However, with sufficient annoyance, one can turn away large numbers of C++ programmers generally, and Boost users specifically.
I find it unlikely that this particular thing would be the one thing to tip the balance away from someone using Boost, and I think you'd agree with that. Otherwise, I agree with what you're saying here, but the tradeoff isn't worth it. I don't have a problem with Boost providing the tools to apply the workaround (i.e. BOOST_SEMICOLON) locally. I don't even have a problem with Boost headers that define the types of macros we're talking about here #include'ing that definition--just to make it as easy as possible for the user to apply it. The main difference is that the library source contains the pure form, and any workarounds are explicit.
If you let people add a semicolon after the macro, how can you change the macro later in a way that doesn't tolerate a trailing semicolon? The expansion of the macro is an implementation detail; the interface shouldn't depend on a particular expansion.
I have, in fact, seen situations where this arose. One has to visit many files to remove trailing semicolons if one uses a compiler that complains about the extras.
On that basis, I am convinced that semicolons should be kept within the macro. Indeed, I plan to follow that approach in my own code henceforth, despite the formatting trouble it will cause.
To be the devil's advocate, it isn't very hard to keep a "namespace-scope macro" requiring a semicolon in the face of change, if being able to add a semicolon is a priority for you. Regards, Paul Mensonides