From: "Paul Mensonides" <pmenso57@comcast.net>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
First, Paul contends you can fix code indenters, but how? Really, when an editor sees a line that has no statement ending token, it has to assume it continues the previous line.
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.
result of the syntax not being static. I.e. the syntax is not represented by the source code, but is derived from the source code by a preprocessor.
After all, whitespace can appear throughout C++ code. I see no way for an indenter to "Do the Right Thing(TM)" in this case.
It has to be able to do macro expansion, it's that simple. Whether or not that easy to integrate is another story, but it isn't impossible. 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. 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. Thus, by your definition, there cannot be a "robust C++ editor" unless we eliminate the preprocessor.
Second, adding or omitting a semicolon will *not* change a programmer's understanding of the preprocessor. I know many programmers who will simply add a semicolon or not as the compiler and indenter dicate. They won't give it any more thought than that.
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 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. Having said all of that, I find the following compelling: From: "Peter Dimov" <pdimov@mmltd.net>
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. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;