|
Boost : |
Subject: Re: [boost] boost.org Source-Code, Concepts & Idioms.
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-10-14 19:28:28
> > 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).
> >
> Is there also a hook to decide if an #if #else expression should be
> evaluated or left as it is?
Sure. Just have a look at the docs for the full set of preprocessing hooks
or at the file boost/wave/preprocessing_hooks.hpp
But on a second thought, you probably don't want to evaluate the #if/#endif
etc. yourself, this might turn out to be serious business and is best left
to Wave.
> > 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.
> >
> Are you saying that we need to inline the headers or wave wont see the
> macro definitions?
Currently yes. At least that's the default behavior of the library.
> Would it be possible to split the parsing of includes from the inline
> expansion?
I think it is possible. Again by adding some code to the
found_include_directive() pp hook. All you have to do there is to use the
context object passed to this function to preprocess the include file,
eating up all generated output and returning true afterwards to make the
library skip this include. Since you have been using the same context to
preprocess the include file, all macros have been expanded and the
wave::context object is the same as if the library itself was preprocessing
the file.
> I expect that we do need the defined macros from included files if we
> want everything correctly evaluated. But if it is to be readable no
> headers should be expanded. We want the source files to look like hand
> written code.
Agreed.
Regards Hartmut
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk