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

From: Daryle Walker (darylew_at_[hidden])
Date: 2005-12-12 02:45:57

On 12/12/05 12:35 AM, "Max Motovilov" <max_at_[hidden]> wrote:
[Paul Mensonides wrote:]
>> 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.
> 
> We probably disagree about the short-term costs, not the long-term ones. The
> long term costs are an incremental and mounting burden, short-term costs are a
> barrier to entry. E.g. if the new compiler (VC7.1 for the sake of the
> argument) does not compile the existing code base, the management keeps
> everybody stuck with the old one (VC6 in this example) and bye-bye Boost, or
> most of it anyway. Yes, in principle it would have been better to resolve a
> few minor things such as incorrect scope of 'for' variables, or whatnot, but
> it's anyone's guess how it will turn out in every particular case.

I think one of your fundamental assumptions is bad.  You're insisting that
Wave has its preprocessor bug-for-bug compatible with major compiler(s),
specifically MSVC++.  However, AFAIK, we are _not_ competing against the
actual implementations out there.  We are doing something akin to research,
not trying to conquer other products.  If you want something bug-for-bug
compatible with a published[1] preprocessor, then use that preprocessor (or
something marketed as a work-alike).  Don't try to use Wave then complain
that our features aren't competitive.

Our goal for Wave is getting a preprocessor/compiler library that is as
close to being theoretically perfectly conforming as possible.  Any changes
to Wave would generally be for gaining standard conformity.  Sometimes we
optionally include considerations for current practices (e.g. allowing '$'
in identifiers).  But we don't want to go crazy on this because the time to
implement every quirk on every compiler out there would take up our time for
actual improvements.

By going for perfect conformance, Wave can serve as an inspiration or a
check for other compilers out there.  I think someone else here said that
Wave could also help in researching how far higher level techniques could
go.

[1] I wanted to say commercial, but that would exclude the F/OSS full-blown
compilers out there (like GCC).

[SNIP]
> I wonder if the best thing that could possibly happen to C++ at the moment
> would be a 4th edition of Bjarne's book, based on Boost in the same degree as
> 3rd was based on the standard library. I know there are good recent books that
> explore certain corners of modern C++ thinking, but they somehow don't seem to
> resonate. What little I've seen of college-level C++ curriculum looked quite
> atrocious. And in terms of continued education, there's just not one _single_
> book that I could recommend to junior guys and tell them "write like THAT". In
> my mind, "like THAT" being -- learn to use and actively search for available
> library code and don't be scared if IT uses advanced paradigms -- YOU don't
> have to.

Maybe Bjarne could study Wave (in the future) for some inspiration.

> 
> But then again, even a new Bjarne's book might not cut through all the hype
> the industry is always awash in :(
[SNIP]
> I think for starters it would be nice to get it better adopted by other parts
> of Boost (not a dig at you by any means, but at those who can't be bothered to
> use it). There's just no excuse for a library to introduce an arbitrary,
> unconfigurable limit on the number of supported arguments in a user's
> function, or length of a [variable by design] list of template parameters etc.
> The only piece of Boost I have to replace with my own version in every new
> release is boost/tuple/detail/tuple_basic,hpp which is STILL limited to 10
> elements and which I had rewritten using Boost-PP back in 2003... by the way
> if anyone DOES want it in Boost after all I'd be glad to re-submit ;)

Someone gave me patches to convert base_from_member to use the Boost.PP,
which was also originally stuck at 10 constructor arguments at the most.
Maybe you should re-submit a patch for Boost.Tuple.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com