Re: [boost] boost.org Source-Code, Concepts & Idioms.

Subject: Re: [boost] boost.org Source-Code, Concepts & Idioms.
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-10-14 12:04:46

> >>> I don't think it is really feasible to maintain two versions of the
> >>> code.
> >>>
> >>
> >> Do we really need to. Would it be possible to modify Wave to do a
> >> selective preprocessing of the source?
> >
> > This could be quite a task if we want the output to be more readable
> that
> > the input.  For instance some macros should be expanded but others
> > shouldn't be.
> > (Do users really want to see the implementation of BOOST_TYPEOF?)
> >
> Suppose that it would be possible to declare which macros are to be
> considered defined, which are undefined and which are still undecided.
> Wave would use the information on defined or undefined macros and
> resolve preprocessor directives using them, but leave undecided macros
> untouched.
> There could also be a option to prevent macros matching %pattern% to be
> expanded.
> 
> Would that not be enough to allow for fine tuned generation of readable
> workaround-free code (or preprocessing source for specific platforms)?

If you have a list of macros to leave untouched it is easily implemented.
All you (somebody) will have to do is to modify the
expanding_function_like_macro() and expanding_object_like_macro()
preprocessing hooks to return true for all macros Wave shouldn't touch (see
tools/wave/trace_macro_expansion.hpp).

You probably don't want system headers to be expanded, though. As long as
you don't care about the defined macros in those headers you can skip
processing of certain include directives the same way as above: change the
found_include_directive() preprocessing hook to return true for the
#include's to skip.

The readability of the output is another issue. Wave allows to control the
amount of whitespace: eat all whitespace, leave comments only, leave all
whitespace. The second option is probably the best, but I'm almost positive
this will eat leading indentation as well (which would have to be fixed).

Overall, worth a try, I think. Somebody up to this?

HTH
Regards Hartmut