So I was working on my prime array initializer when I ran into a run away recursion. The logic seemed pretty good to me so I searched the net for meta programming debugging techniques. I didn't find any but I did find a bunch of complaints about the error messages that tend to be the result of TMP.

Boost was singled out as particularly awful. Adding Boost libraries can significantly increase compile times and significantly obfuscate error messages coming from the compiler. Boost uses a great deal of template meta programming which generates code at compile time -- which means that errors can occur anywhere within the generated code and can be particularly difficult to troubleshoot.

So what are your thoughts on Boost and its heavy reliance upon meta-programming?

Since nobody else is replying, I'll pipe in. I have only just recently download the Boost library, and haven't had a chance to do anything with it, since I'm learning API GUI programming. I wanted to learn the API before diving into Boost. Boost seems like it's got some good features.

As far as meta-programming...huh? Speak english lol

Well I am particularly intrigued by Boost -- at the moment Xpressive which is a Regex library that can build the regular expressions at compile time.

Although from what I am getting on the internet Xpressive is actually slower than other regular expression libraries (even though you would think that with so much work being done at compile time it would be faster -- in fact some people have written that very thought -- but the evidence seems to be to the contrary).

But when you make a simple syntax error in an Xpressive expression you get a terribly long complicated error that is not very helpful in helping you discover what you did wrong.

Boost has some really nice libraries. In fact, I'd venture to guess they're all very good. However, the program options, regex, and filesystem libraries are the extent of my use, and they came in very handy.

In many situations where regex use is heavy, evaluation needs to happen far more times than compilation, so if the evaluation is slower in Boost.Xpressive (which could be due to compromised compilation quality due by not having a full programming language), the end result is likely to be similar.

I find that if one sticks to using the Boost libraries in a similar manner to the examples provided in the documentation, the libraries are usable with little difficulty. If one goes outside of this, then problems tend to occur, especially regarding using non 8-bit character types. While boost.regex does work with 16-bit types, it does not actually understand UTF-16. I was unable to get boost.iostreams to work with wide characters, and the source code for boost.iostreams is very unreadable.

It's amazing what some of the boost libraries do (boost.lambda is another interesting one), but I think that there are many practical issues that need to be addressed. Some of the libraries are more like research projects than production libraries, while others are very useful and down to earth (like boost.regex and the smart pointers). In the event that someone really needs compile-time regex compilation, it could probably be better solved with an additional tool than directly with the template language. But then again, boost.xpressive is relatively new, so it will be interesting to see where it goes.

There is definitely some interesting things going on. I have been taking a close look at some of the libraries and while some are WAY over my head at this point I have managed to pull quite a bit down to my level and digest. For example the preprocessor libraries are incredibly interesting -- along with little things like the FOR_EACH macro which is quite a neat little bit of hacking.