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"
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