From: KSpam (keesling_spam_at_[hidden])
Date: 2007-05-25 13:42:59
I also find BOOST_PP extremely convenient. I used to write all kinds of
autogeneration tools in Perl and Python. I found that BOOST_PP solves the
majority of my problems more elegantly. I just wrote a parser in Spirit the
other day, and I found that BOOST_PP reduced well over a thousand lines of
code into a few hundred.
BOOST_PP really shines for tasks that are small in scope but highly
repetitive. Often with BOOST_PP, a couple lines will do. An external
process would require that you:
1) Write a custom tool (external to the source code, so the "paper trail" is
harder to follow)
2) Plumb that tool into the build process
3) Ensure that all target systems have the necessary environment (external
tools, environment variables, etc) to accomplish steps 1 and 2.
If you are worried about portability, the steps above just got a great deal
more difficult.
In contrast, BOOST_PP just requires a couple lines of code that are
conveniently inline with the source code. The build system integration and
target system environment is a non-issue.
I have come up with a few cons while working with BOOST_PP. There is a
learning curve, which is probably on the order of learning a new scripting
language. The syntax is not as elegant as Python, but what do you expect
from the preprocessor? Syntax and usage errors can be notoriously difficult
to track down. I need to learn wave (and the incremental debugging options),
as I am certain that wave would render this a non-issue. Finally, Doxygen
documentation is impossible to do in code generated with BOOST_PP. This is
the only "real" issue as far as I am concerned. I wonder if there is a way
to get that working with the help of wave.
Anyway, I refuse to go back to a world prior to BOOST_PP. I am a very
satisfied user!
Justin
On Friday 25 May 2007 09:08, Arkadiy Vertleyb wrote:
> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote
>
> > If your goal is to generate some repeatative code, you could probably get
> > away with your own generator. I suspect most applications of Boost PP
> > are just like this.
> >
> > OTOH, if you want to define a macro which expands according to parameters
> > provided by your macro users, your generator will not help you, but Boost
> > PP will, and it will help you tremendously.
> >
> > As an example, the implementation of typeof emulation in Boost.Typeof
> > would not be possible without Boost PP (or a similar library).
>
> Second thing, it's just plain more convenient. Instead of writing your own
> code generator as a separate app, then including it in the build process,
> you just deal with all the code generation right in your source file. If
> you are writing a library, especialy header-only library, you would not
> want to tell your users they need to install an additional application, and
> include it in their build process, just to use your lib.
>
> I guess this is why Boost PP is used so extensively by other Boost
> libraries.
>
> Regards,
> Arkadiy