|
|
Boost : |
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-15 16:34:51
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
> > ...which is no different than any other syntactic error
> that one might
> > make when typing, and is usually the easiest kind of error to fix.
>
> It is different in that many compilers won't detect it.
But it is a triviality. I understand the problem, but I fail to see how the
problem is anything but slight, especially given the cirumstances where it could
become significant. In those circumstances, the likelihood of this being the
showstopper is extremely low.
> > The intentionally strong language is about people that habitually
> > expect that semicolons after macro invocations at namespace
> scope are
> > supposed to be there.
>
> Well, some part of my brain obviously expects that habitually.
Then you're perspective needs to change so that it doesn't. I except that you
in particular don't have any serious problems with the issues that I'm harping
on, but that's probably because of your familiarity with preprocessor
metaprogramming. This isn't about preprocessor metaprogramming per se, but
about macros in general (obviously, any macro is a metaprogramming construct,
but I think that you understand the distinction that I'm making).
> >> > 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.
> >>
> >> It depends whether you're the person at liberty to change the code.
> >
> > ...and you can't get those that are to fix it--which means
> that you're
> > attempting to use source code on a compiler that it hasn't
> been tested
> > on without the ability to modify it at all.
>
> I'm just trying to say that modifying the code is much easier
> for some people than for others. If you're the author, it's
> usually trivial, but all sorts of restrictions get in the way
> for other people, to varying degrees.
I know, but you're projecting this problem into a circumstance where there are
so many potential problems that the likelihood of this being the one thing that
prevents reuse is extremely low. That circumstance (to reiterate) is attempting
to use source code on a compiler that the code hasn't been tested on without the
ability to modify it in any way.
> >> It sounds like you're saying:
> >>
> >> - Some naive users think macros are the same as functions
> >
> > I'm saying that *most* users, naive or otherwise, view (for
> example) a 'max'
> > macro as returning the greater of two (or more, I suppose)
> arguments.
>
> I see where you're coming from.
To try to be a little more clear, "...as returning, for all intensive purposes,
the greater of two arguments." That is, not confusing it with a function, but
confusing a syntactic effect with a semantic one.
> >> - That causes them to make mistakes
> >
> > Indeed, except with what I said.
>
> Huh?
Confusing syntactic effect with semantic effect causes mistakes.
> >> - Thererefore we should design all macros to forbid a trailing
> >> semicolon in order to discourage that misconception
> >
> > No, we should design macros without this being relevant. Generally
> > speaking, we should define them to be self-contained entities that
> > produce self-contained syntactic constructs.
>
> Okay, that's a more refined point-of-view.
I'm definitely not saying that we should intentionally design macros to *not*
look like functions. I'm saying that we should not intentionally design macros
*to* look like functions.
> > I'm not referring to someone that is so naive that he
> doesn't know the
> > difference between a macro and a function. I'm referring
> to typical
> > C++ programmers, including just about everyone involved in this
> > conversion, that thinks that making macros look like underlying
> > language syntax is a valid goal.
>
> I understand you to have two objections to that point of
> view, which can be summarized as
>
> - It leads some people to think that max(a,b) is a function call
Not a function call, a semantic effect.
> - it is self-perpetuating.
>
> I understand the first objection, but to buy into the 2nd one
> I have to accept that it's an invalid goal before I can
> believe the reasons you give for it being invalid. So far
> that looks like a leap of faith.
It is an invalid goal because it intentionally blurs the distinction between
syntactic and semantic effects. A lack of formal distinction leads to
macro-related bugs that are the main reasons for the antipathy towards the
preprocessor. I.e. it's unsafe, etc..
> > It causes errors far more insidious that extra semicolons.
>
> What sort of insidious errors do you think I make because of
> that point of view?
Not you specifically, C and C++ programmers in general. One such mistake is
multiple evaluation with side-effects (or even without them).
> >> - How much easier it makes things when the macro requires the
> >> semicolon
> >
> > How much easier does it make things? I'll that I've seen
> here is 1)
> > editors don't indent properly because they can't handle it, and 2)
> > extra semicolons aren't caught by some compilers making the code
> > non-portable.
>
> and 3) many people find it "more natural."
Which is the part that I most disagree with.
> We have had
> reports in this thread that the semicolon sometimes comes up
> automatically, and not seeing the semicolon causes people
> some "cognitive dissonance."
Where "cognitive dissonance" means "having to view things from a superior and
more technically correct perspective."
> > I'm not saying these are absolute non-factors, I'm saying
> that neither
> > is a strong enough argument to violate (what should be) the
> principle
> > and therefore propogate the same problems that we've had with the
> > preprocessor for years and years.
>
> Somehow I have trouble seeing a tiny design choice like this
> one as the cause of those problems.
It propogates the laudability of explicitly designing macros to look like
syntactic entities. E.g. "Boost does it, therefore it must be good."
> >> - That requiring the semicolon can keep a category of
> errors from
> >> creeping into code
> >
> > Except that it isn't preventing some kind of insidious error.
> > Instead, its a trivial error that is trivially fixed. I
> don't think
> > that you can reasonably expect to use some source code with
> a compiler
> > that it hasn't been tested on without having to change it at all.
> > Extra semicolons are the least of your worries then.
>
> Somehow, I do have that expectation though.
I seriously doubt any non-trivial piece of source code that contains no
workarounds for a particular compiler and has not been tested on that compiler
can be used "out-of-the-box" on that compiler--at least, not with C++. If we
ever approximate the ideal of having portable C++ (meaning nearly all compilers
approximate the standard very very closely) then this issue shouldn't come up
because compilers would flag it as an error. Until that point, I don't think
it's realistic to have that expectation.
> > Your own positions are rarely less than heavy-handed. This isn't a
> > piddly little case of some silly misconceptions. It is a pervasive
> > viewpoint that is flawed, which leads to errors, and which leads to
> > broad denouncement of the preprocessor. It is an erroneous
> > perspective, not a misunderstanding of the differences
> between macros
> > and functions.
> >
> >> For my part, I think my priorities are exactly inverted from yours.
> >
> > Then make another Boost policy.
>
> 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.
> > 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. 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.
> >> >> 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.
> >>
> >> I _thought_ for a minute I understood what you meant by "from the
> >> point of view of other source code," but now I'm less
> sure. Seems to
> >> me "other source code" doesn't care about convenience and
> usability;
> >> only its author does.
> >
> >>From the point of view of other source code in terms of the source
> >>code complexity and size of a use of a construct.
>
> Sorry, I don't understand yet.
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.
> 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. 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.
> > Except that in this case (the expression of a library
> feature), you're
> > severly underestimating a sound principle by letting it be
> outweighed
> > by the possibility of extra semicolons (which is quite possibly the
> > easiest bug to fix of all time) and by automatic formatting of some
> > editors that many people use (but many people don't).
>
> Yeah, so far that's how the balance tilts for me. I
> understand your point of view better now, but still am not
> persuaded to raise my estimation of the importance of that principle.
The effect in this one particular instance is trivial. The effect of this being
a generally agreed upon "best practice" is. This particular case is just one
small addition to the mountain of bad code produced by the so-called "best
practice".
> >> > 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.
> >>
> >> If that was my motivation, I'd agree. But in fact requiring
> > ^^^^^^^ This isn't a
> > fact; it's your opinion. Most people that want to be able
> to add the
> > semicolon (AFAICT) just think it's more syntactically pleasing.
>
> 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. But it doesn't, and
all this does is make it look like the macro is something that it is not.
Regards,
Paul Mensonides
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk