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