-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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