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

From: Hartmut Kaiser (HartmutKaiser_at_[hidden])
Date: 2005-02-09 02:35:15

Gennadiy Rozental wrote:

> > The Wave C++ preprocessor library review begins today February 7, 
> > 2005.
> 
> 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? Note I do not comment on the 
> quality of the submission (I most probably is not qualified 
> enough to comment on that). After all this library/utility 
> exist already and available to public.

IIRC it was discussed several times on this list, that
- Boost should be more than a collection of libraries, it additionally
should provide the C++ developer with general tools usable to improve there
work. 
- 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.
- 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.
- 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.

> 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.
Certainly I do have a comprehensive test suite here (otherwise I wouldn't
have been able to make the library such compliant as it is), but this isn't
a fully automated test suite yet and I currently can't give it away. But I
agree with you: there should be such a test suite and I'd be willing to
provide one given Wave will be accepted into Boost.

To answer your question regarding how you may test whether the library does
what it claims: just take your everyday code and pass it through Wave before
compiling (just as you do with other compilers you trust). 

But perhaps others who have used Wave may want to comment on the issue of
compliance as well.

> 3. How are we supposed to comment on implementation?
> Beyond a sheer volume of submission (more that 1 meg in 
> headers and sources), IMHO one needs to be an expert in both 
> Spirit and C++ preprocessor specification to make any 
> intelligent comments on what is written.

I think you won't have to understand every bit in a library to give a
judgement. Looking at the documentation and skimming over the code often
gives a good impression about the quality of it. 

> 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.

BTW: part of these headers aren't required to compile a program using Wave
(especially the files related to the grammars). Part of them are required to
compile the libraries only. So the question is, where to put these headers.
I've put them all into one place (the boost/wave subdirectory) to comply
with the Boost directory structure. But this is an issue I'm ready to
discuss about. In the end it doesn't matter for the overall Boost size,
where these files will end up: in the boost/wave or the libs/wave directory.

If you look at the main header of the Wave library (it's the file
cpp_context.hpp), which is the one containing the public interface, you'll
see, that it exposes a really sparse public interface (as described in the
documentation): 
- predefining macros, 
- managing include paths, 
- perhaps adjusting some additional parameters (as the mode to work in, i.e.
C++ or C99, or the max allowed include nexting depth), 
- getting the current state the preprocessor in working in, and 
- getting the iterators to work on. 

Nothing more.

The overall Wave codebase is heavily structured into namespaces (reflected
by the directory structure) and the only classes in the boost::wave
namespace are the context<> template and the iterators returned by the
context<>. All the other classes reside in deeper namespaces (such as
boost::wave::util) because they aren't part of the public interface.

Hope this answers your questions.
Regards Hartmut