RE: [boost] Re: Wave C++ Review Begins Today - February 7, 2005

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-02-09 06:41:11

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Hartmut Kaiser

> Gennadiy Rozental wrote:

> > I obviously did not have chance to look into this submission in 
> > details (though it does seems like a quite an achievement), 
> but I have 
> > couple general questions:
> > 
> > 1. Why do we need it?
> > I mean why do we need it here in boost? I admit there maybe couple 
> > dozens people in a world who are interesting in implementing/use 
> > custom C+ preprocessors, but does it make it a widely reusable 
> > component?

A C/C++ preprocessor is certainly a widely reusable (and reused) component.
Obviously, source code reuse is going to be significantly less than a less
specific (and considerably simpler) component like shared_ptr, but so what?  C++
programmers could benefit greatly from tools that currently don't exist largely
because the language is so complex.  A library-based preprocessor simplifies the
task of analysizing C++ source considerably.  Because of realities like that,
direct reuse isn't the only type of reuse worth pursuing.

Furthermore, it comes down to whether or not it is possible for something to be
too specific to be part of Boost, and, if so, where that line should be drawn.
There is already precedent in Boost for highly specific (non-general purpose)
libraries--such as the Python library.

> - many Boosters agreed on that it would be a good thing for 
> Boost to have a publicly available C++ compiler (or at least 
> parts of), which may be used for a broad range of tasks (just 
> remember your recent discussion with Christopher, where the 
> idea of having a C++ refactoring tool (to add intrusive 
> profiling) popped up again). And I assume a preprocessor is 
> an integral part of such a tool suite, just the first step 
> towards this goal.

This is an example of indirect reuse--user X may not care about Y, but user X
does care about Z which uses Y--which might even be more important in the
overall scheme of things.  That happens all the time with libraries like the
type_traits library, the MPL, and the pp-lib.

> - Boost is the melting pot for the next C++ Standard 
> (currently mainly for the library working group), but only 
> having available a codebase to play with we'll be able to 
> test different aproaches to make the preprocessor more 
> usable. Just take the recent discussion about macro scopes 
> and such. Without a reference implementation in our hands 
> it's very hard to judge the strengths and weakness's of a 
> particular proposal.

I'll second this as well.  IMO, as a generalization, the library working group
is much more focused on reality rather than theory.  It is often the case that
they know better what we actually need.  (No offense is intended by that
comment, BTW.  It has simply been my observation.  How many template facilities
where added because of the STL, for example?)

> - Wave may be a helpful tool which could be used by 
> developers sticking with older compilers (and bad 
> preprocessors) but wanting to use the Boost.PP library in there code.

Or libraries that are much better than the pp-lib... :)

> > 2. How are we supposed to test this submission (by test I
> > mean: make sure it works correct)?
> > The submission package does not include any tests, while 
> with utility 
> > of this complexity, I actually expected compliance testing 
> facilities 
> > to exceed in side the implementation.
> 
> Very good point. I must admit, that I underestimated the 
> significance of adding an integrated test procedure to the 
> Boost submission package.

Though not directly relevant to Gennadiy's point (and not in opposition to it),
testing against Chaos far exceeds the rigor of any C or C++ validation suite
currently in existence.

> > 4. Why would you need 500k of headers?
> > After all public interface should be something around: take 
> this file, 
> > parse it, produce a text output?
> 
> That's very much related to your 1st question. 
> If we agree on to make Wave a part of Boost to meet the goals 
> I've re-iterated above, you'll have to take the burden of 
> adding these headers to Boost as well.

Note also that a preprocessor is a non-trivial entity.  There are several
general purpose facilities that Wave must implement itself because they aren't,
for example, in Boost--such as a copy-on-write string (which is a very valid
option in single-threaded code).  If some of those general purpose components
were in other libraries (or were libraries themselves), Wave's size would
decrease.  As a case in point, Wave would be bigger yet if it didn't reuse
Spirit.  Likewise, it is a template-based library, which makes it more
extensible (i.e. Unicode source files, etc.) without resorting to unnecessary
runtime dispatch.  That also increases the header size.  Generic code is simply
bigger than non-generic code--10% actual code, 10% regurgitating typedefs, and
80% 'typename' and 'template'. :)

Regards,
Paul Mensonides