Re: [boost] Re: Preprocessor Library

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-10 18:36:13

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
news:a92cnh$d42$1_at_main.gmane.org...
> David Abrahams wrote:
> > 1. I need to pre-generate a large number of repetitions for most EDG
> > compilers, which it seems basically can't handle any PP lib constructs,
> > making me wonder how much the PP lib is really buying me.
>
> It still frees you from going through N (consequently more complex, but
> essentially the same) copies of code when its interface/implementation
> changes.

Of course.

> > 2. It moves the generated examples far from the PP code which they help
> > to document.
>
> It's true. However, I find that after you become familiar with the
library,
> you don't really need to see the expanded version in oder to understand
what
> is being produced by generator macros.

Yes, but the barrier to entry is SO high, and that makes it very difficult
for the next guy who wants to make a fix/tweak.

> You often _do_ need to see the result
> of the expansion in order to fix typos etc., and here the expanded headers
> are a big help, but again, personally, when doing that, I don't find it a
> problem that the generator and the expanded code I am debugging lie in
> separate files.

It's always relatively easy for an expert, but I'm trying to leave a trail
of breadcrumbs...

> > 3. I still don't have a good way to quickly clean up the output. I think
> > it would be fairly trivial to implement something, but that's an extra
> > step I haven't taken yet.
>
> That's the part I am still struggling with as well. After looking at all
C++
> code beautifiers I could find, I am inclined to just sit and write a
> 100-lines python program that would do what I want :).

I am having good luck with a series of regexp replaces followed by
indent-region in emacs:

" *\(\s.\) *"  -> "\1"      remove whitespace to either side of punctuation
" +"           -> " "       remove duplicate spaces
"\([{}]\)      -> "\n\1\n"  separate line for braces
";\(.\)"       -> ";\n\1"   newline after ;

> > 4. Things aren't so simple when there conditional compilation to work
> > around compiler bugs is involved.
>
> Yep. I don't have real experience of dealing with this issue, but I was
> thinking about something along these lines:
>
> #if !defined(BOOST_MY_LIBRARY_GENERATOR_MODE)
>
> #   define BOOST_MY_LIBRARY_HEADER \
>     BOOST_PP_STRINGIZE(
>         BOOST_PP_CAT( \
>           BOOST_PP_CAT(
>               my_library/preprocessed/my_header \
>             , BOOST_MY_LIBRARY_COMPILER \
>             ) \
>         , .hpp) \
>         ) \
> /**/
>
> #   include BOOST_MY_LIBRARY_HEADER
> #   define BOOST_MY_LIBRARY_REPETITION_START 5
> #   define BOOST_MY_LIBRARY_REPETITION_END 15
> #else
> #   include
> #   define BOOST_MY_LIBRARY_REPETITION_START 0
> #   define BOOST_MY_LIBRARY_REPETITION_END 5
> #endif
>
> #if ( defined(BOOST_MY_LIBRARY_COMPILER) \
>     && BOOST_MY_LIBRARY_COMPILER == BOOST_MY_LIBRARY_COMPILER_MSVC65 ) \
>     || ( defined(BOOST_MSVC) && BOOST_MSVC < 1300 )
>
> #   define AUX_MY_CONSTRUCT_GEN(i) \
> template< BOOST_MPL_PP_PARAMS(0,i, typename T) > \
> struct my_construct { /* more stuff */ }; \
> /**/
>
> #else
> #   define AUX_MY_CONSTRUCT_GEN(i) \
> ...
> /**/
> #endif
>
> Here, to produce a version of expanded headers for, let's say, MSVC, you
> invoke the compiler in preprocessing-only mode with two macros defined -
> BOOST_MY_LIBRARY_GENERATOR_MODE and BOOST_MY_LIBRARY_COMPILER ==
> BOOST_MY_LIBRARY_COMPILER_MSVC65. The compiler you use for generation
> doesn't have to be the same as the one you produce the headers for.

Fortunately, the cases I'm dealing with are still pretty simple and don't
need a formalism like that yet.

-Dave