"Paul Mensonides" <pmenso57@comcast.net> writes:
Now _that_ would be heavy-handed :)
Yet we have some of those policies already. One example is tabs in source files. It is a total non-issue except in one situation: using tabs in the middle of a line of code rather than to indent it.
Actually, no. IIRC it's a GNU convention to use 8-space tabs and indent in multiples of 4 spaces, so lines start with a sequence of zero or more tabs and successive levels of indentation end either with a tab or with 4 spaces. When I change my tab width to anything other than 8-space tabs, nothing looks right. If I change to 3-space tabs I can even get the indentation to invert. Now, you can tell me "I meant to rule that case out too," but it just goes to show that it is a nontrivial thing to create a policy that actually works. I really don't want to get into an argument about whether the Boost tab policy is wrong or right... like many other things I've been discussing today, the Boost policy (ca. 1998) is in place for practical reasons. If someone could find a simple and proven policy that allows tabs at the beginning of a line and is easy for everyone to follow without silly misinterpretations, I'd be fine with it. We didn't have time -- or maybe enough smarts -- or maybe enough people who cared enough about being able to use tabs -- back then, to figure out how to be maximally permissive without causing problems. We wanted to get about the business of building Boost, and that policy is what we ended up with.
My priorities revolve around making things as pure as possible given the environments that we have to deal with. If that is divergent with Boost's priorities, then consider it the end of my affiliation with Boost.
Wow. I don't know what to say.
I don't know about the priorities of the rest of Boost, but I guess purity is a lower priority for me than some other things.
My conception of Boost, and the basis for my involvement (for whatever its worth), is that Boost isn't just about providing tools to get the job done. It's about providing tools--written the right way--to get the job done the right way to the greatest extent possible given the compilers and platforms that we have to deal with.
Right. But, people of goodwill and reasonable intelligence can disagree about how to evaluate "the right way." It's not an absolute.
If that isn't part of it, I have no interest in sticking around. Catering to editors in the face of purity is taking "compilers and platforms that we have to deal with" to the point of being asinine.
Are you being intentionally insulting? FWIW, one of the main reasons I brought this issue up was that I was hoping you'd convince me that the reasons to do it your way were important enough to outweigh the reasons to go the other way.
It is certainly in terms of the convenience and usability of the author, but in terms of the complexity required for a use of a construct to be understood by the author and the terseness or verbosity of the expression of that construct by the author. Having no semicolon doesn't make it significantly less convenient nor does it increase complexity. Rather, it merely requires a programmer's perspective to be a little different--but not in a way that is difficult to grasp.
Trivial things do add up.
I see. Well, I still maintain that
#define MACRO struct xyz {
MACRO };
is a different category of beast.
Not from my perspective. In both cases, a standalone entity is started, but not finished--for no good reason.
That last part is debatable, but aside from that what you say is true. OTOH, the case above does not complete any syntactic entity at all, whereas the struct declaration without the trailing semicolon does. Of course, the thing I want to do completes one standalone and one non-standalone syntactic entity, so maybe it's in another category still.
The only difference is that MACRO }; is obviously different from any normal C++ syntactic construct.
If I *had* to choose between intentionally designing macros to not look like underlying syntactic constructs and intentionally designing macros to look like underlying syntactic constructs, I'd choose the former, but both a flawed constraints. Doing either, IMO, is bad design.
Well, I don't view myself as doing either one, FWIW. "Looking like underlying syntax" is not a design criterion for me.
Don't underestimate how much easier it gets for people to read and write code when it's syntactically pleasing.
If the preprocessor had more of an ability to manipulate syntax or was part of the syntax (as in Lisp or Scheme), then we could do this.
Do what? Are you saying we can't syntactic pleasantness into account because the PP can't manipulate syntax?
But it doesn't, and all this does is make it look like the macro is something that it is not.
Still looks like a code-generating macro to me, with or without the semicolon. -- Dave Abrahams Boost Consulting www.boost-consulting.com