Re: [Boost-users] Wave: how to recover after errors?

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-12-11 21:15:25

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] 
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Max 
> Motovilov

> Paul,
> 
> I hear you :)  The frustration surely breaks through. But, 
> ugly workarounds or not, being _able_ to use tools such as 
> Boost libraries is a very big deal.

I agree.

> And, to a large degree, 
> you are helping drag the [kicking and screaming] compiler 
> vendors into the realm of standard C++ BECAUSE your libraries 
> can be immediately used with MOST of the compilers out there.

To some extent, yes.  Let me be clear.  Despite how much I hate workarounds, I
recognize that they are necessary in production environments.  However, what we
are talking about here is a little different than the usual.  We aren't talking
about source code workarounds for an implementation; we're talking about
implementation workarounds for source code.  Compilers do that for compatibility
with legacy code, usually code that worked with previous versions of those same
compilers.  If compilers had not done that, and had broken code incrementally,
it would have caused an awful lot of work to fix code.  However, it would have
removed a great deal more work later (still ongoing into the forseeable future)
for compiler vendors, library authors, and C++ programmers in general.  The
payoff of permissiveness is short-term and insignificant compared to the
long-term cost.  Maybe we just disagree about how significant that long-term
cost actually is.

> A shaming campaign is a pretty nice twist, I agree -- but 
> just cutting off the non-conforming compilers would mean 
> marginalization.

A shaming campaign is not the intent.  I don't want to shame vendors.  If
anything, I want to encourage vendors.  The intent is to see how much farther we
can go with standard C++ than we currently do on account of implementation
deficiencies.  There are techniques and idioms that are barely usable that
should be generally usable.  That "barely usable" status is a significant
barrior not just to the use those techniques, but the discovery and development
of those that might be built on top of them.  As a concrete example, we have yet
to see the full effect of 'enable_if'.  Workarounds often manifest themselves
implicitly as interface changes, as well as waste the creative time of authors
in both interface and implementation.  As I said above, for production code,
workarounds are often necessary.  However, the necessity of workarounds need not
be at the cost of idealism--which sometimes requires development of parallel or
even diverging branches (which is something that we don't have at Boost).

But again, the above is about source code workarounds for implementations, not
vice versa.  I am completely against any permissiveness in compiler (or
preprocessor) implementations, because that is what propogates the problem at a
fundamental level.

> You may be happy with a few "power clients", 
> I don't know, but there's gonna be a whole lot of unhappy 
> people left in the cold... though _I_ personally can probably 
> get by with M$VC8 :)

Obviously the more clients the better--unless there is another significant cost
that comes with it.  I don't know if its still the same situation now, but a
number of years ago, VB had an awfully large user base.  If C++ had become more
VB-like, it may have come out higher in number of users than it has now.
However, the cost would have been significant.  (Of course, now we get C++
vendors making C++ more VB-like anyway.)  The point is that popularity is not
the only measure of success.  In fact, popularity is often an indication of
lower quality (e.g. MFC and pop music).  Obviously, that is not a generalization
that can be blindly applied, but it is true often enough that it should cause
legitimate skepticism.

Again, I'm not saying that we should stop applying workarounds--which would be
foolish in the extreme.  I am saying that we shouldn't start applying
workarounds in a preprocessor or compiler implementation context, nor start the
cycle of propogated compatibility for misfeatures or bugs in previous versions.

I'm also saying (and this is not related to the primary point) that it would be
nice to have a distinct, clean version of Boost (not an interface-to-interface
mirror image) that, though idealistic, would serve as a breeding ground for the
cutting edge and something to aspire to for vendors.  I'm not just talking here,
I've done it for the part of Boost that I consider my responsibility.  (As
usual, my problem is documentation--very important--which I hate writing and
apparently suck at anyway.)  My first observation based on that experience is
that the pp-lib is stagnant.  There isn't much I can do to improve it (even with
massive workarounds) without much better implementations as the common starting
point.  A second observation is that I know, within my small area of expertise,
how much farther we can go and how much better things can be with better
implementations.  A third observation is that pristine codebases can still serve
as conformance tests for vendors.  The original version of Loki was like that
also.  Once a significant degree of notoriety is achieved the risk of
marginalization is considerably less.

Regards,
Paul Mensonides