On 11/10/03 5:49 PM, "Darryl Green" wrote:

Hi Jon,

...

-----Original Message----- From: Jon Kalb [mailto:Kalb@LibertySoft.com] Sent: Tuesday, 11 November 2003 11:16 AM To: Boost Users Subject: Re: [Boost-users] Intoductory Boost Presentation

On 11/9/03 8:06 PM, "Matthew S Trentini" wrote:

...

Heya Everyone,

I recently gave a presentation to my work colleagues on the wonders of the Boost library. [snip]

Matt,

I don't know if you plan to keep this updated, but here is some feedback from a co-worker. I have not verified his findings.

[snip]

...

...

The rest of the pages have the classic boost downfall: they don't discuss any of the pitfalls, performance problems, or code bloat issues, which frankly, seem like the "crazy aunt in the basement" of boost.

I don't suppose your co-worker would like to enlighten us about these issues/areas with which he obviously has some expertise and considers the documentation (and the code?) deficient? That would be as useful as Matt's overview could be to those just getting into/considering using boost libs. As it stands, all that the above statement adds is FUD.

I passed on my friend's comments without attribution because I didn't ask his permission and I don't think he really intended the comments for so large an audience. His comments were directed to our co-workers and we know a little about some of the research that he has done on some of the Boost libraries. With that audience it isn't exactly FUD. I will forward this message to him and ask if he wants to comment more specifically, but I'll give you one example that he found. I don't recall the exact number, but he found that a function call using Boost::function generated about 20K of code (in our development environment). I realize that in a day when gigabyte hard drives are a dime a dozen it seems miserly to worry about 20K, but that is for *one function call*. I don't think he benchmarked it to see how long it takes to execute this code, but still I think he has a point when he talks about code bloat. I also think he has a point about discussing the performance trade-off issue of each library. When the STL was first introduced, it was so revolutionary that it was given a very skeptical reception. But most people were won over. The power/overhead ratio was very favorable and it looked like compilers would likely improve in ways that would make it even more favorable. Now we are comfortable with template libraries and are less skeptical of new ones. But every library has some overhead cost and has some applications for which it is ill-suited. We need to evaluate each library on its own merits and never assume that because one was accepted in Boost it has some magic property that means there are no performance trade-offs or that the performance profiles of all Boost libraries are similar. Suppose users determine that Boost::function (I'm just picking on this as an example) is great for creating flexible interfaces, but should be avoided for any inner-loop use or where code size is at a premium. That doesn't make the library worthless, in fact, adding advice about the best situations to use the library enhances its value. -- Jon Kalb Kalb@LibertySoft.com