On Fri, May 25, 2007 17:40, Noah Roberts wrote:

Keriask wrote:

...

I just want to find a good reason to use it myself which unfortunately I haven't so far.

Then don't. There are lots of libraries in boost that aren't useful to everyone.

I think you should not bring so much disrespect to people who spent their time to write these libs. And if you just put the lib on the shelf with a sealing "not useful to everyone", some might still use it and even "worse" find it very useful and get some additional ideas/knowledge (sometimes very elegant) on solving their problems. For instance, the likelihood of me using the python bindings

library is about 1 in 1,000,000.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

With Kind Regards, Ovanes Markarian

Malte Clasen wrote:

Ovanes Markarian wrote:

...

...

Then don't. There are lots of libraries in boost that aren't useful to everyone. I think you should not bring so much disrespect to people who spent their time to write these

On Fri, May 25, 2007 17:40, Noah Roberts wrote: libs.

It's not disrespect, it's just ambiguity. I guess he meant

aren't (useful to everyone)

and not

(aren't useful) to everyone

There's no ambiguity. The second use would require a comma.

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

Eric Niebler wrote:

There is. I use wave as a Doxygen filter when generating the docs for proto. The relevant parts of the Jamfile look like:

wave-command = [ path.native ../../../../dist/bin/wave ] ;

# Generate reference section using Doxygen doxygen protodoc : [ glob ../../../../boost/xpressive/proto/*.hpp ] : doxygen:paramEXTRACT_ALL=YES doxygen:paramHIDE_UNDOC_MEMBERS=NO # Use Boost.Wave to preprocess Proto's source doxygen:param"INPUT_FILTER=\"$(wave-command) \\ -S ../../../.. \\ -S \\\"C:\\Program Files\\Microsoft Visual Studio .NET 2003\\vc7\\include\\\" \\ -D _WIN32 \\ -D BOOST_PROTO_DOXYGEN_INVOKED \\ -p 1 \"" # This ensures that Wave is actually built before we [snip]

This lives in CVS head at libs/xpressive/proto/doc/Jamfile.v2. Sadly, I've had to hard-code the standard include path. I don't know any other way.

What I could do is to introspect the $INCLUDE environment variable and append the paths therein to the include search path. Would this help? Regards Hartmut

Eric, Thanks for the info. The process appears easier than I thought it would be. I agree that it is unfortunate you have to hard-code the standard path. Since the path is only necessary to resolve standard headers and you do not need to produce documentation on those headers, do you really need wave to be able to find the standard headers? Is the path required to prevent warnings? Would it be possible to put the standard header include statements inside an ifndef BOOST_PROTO_DOXYGEN_INVOKED block? I am sure that I do not fully understand the problem. Either way, I appreciate the description of the process. Now I am off to build wave ... Thanks, Justin On Friday 25 May 2007 12:02, Eric Niebler wrote:

KSpam wrote:

...

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.

There is. I use wave as a Doxygen filter when generating the docs for proto. The relevant parts of the Jamfile look like:

wave-command = [ path.native ../../../../dist/bin/wave ] ;

# Generate reference section using Doxygen doxygen protodoc

[ glob ../../../../boost/xpressive/proto/*.hpp ]

doxygen:paramEXTRACT_ALL=YES doxygen:paramHIDE_UNDOC_MEMBERS=NO # Use Boost.Wave to preprocess Proto's source doxygen:param"INPUT_FILTER=\"$(wave-command) \\ -S ../../../.. \\ -S \\\"C:\\Program Files\\Microsoft Visual Studio .NET 2003\\vc7\\include\\\" \\ -D _WIN32 \\ -D BOOST_PROTO_DOXYGEN_INVOKED \\ -p 1 \"" # This ensures that Wave is actually built before we try to execute it <dependency>../../../../tools/wave/build release ;

xml proto

proto.qbk ;

boostbook standalone

proto

xsl:paramtoc.max.depth=3 xsl:paramtoc.section.depth=3 xsl:paramchunk.section.depth=3 <dependency>protodoc ;

This lives in CVS head at libs/xpressive/proto/doc/Jamfile.v2. Sadly, I've had to hard-code the standard include path. I don't know any other way.