-----Original Message----- From: Jon Kalb [mailto:Kalb@LibertySoft.com] Sent: Wednesday, 12 November 2003 7:22 AM To: Boost Users Subject: Re: [Boost-users] Intoductory Boost Presentation

...

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 agree - FUD is audience dependent. I am 100% serious about thinking that any addition that clarifies what the issues/pitfalls are would be valuable, while FUD definitely isn't.

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'm sure he has a point. I only asked him to make it. I don't really want this to turn into an attack on your co-worker's reasearch - I would honestly like to see some information on these issues. We did some basic tests on the performance of boost::function before using it and found that the actual despatch overhead is very low (which was our main concern at the time) and the size of the actual function wrapper is acceptable. We have not (yet) used boost::function in a context where the allocation performance would be expected to be significant. We didn't specifically check code size, but I can safely say we don't see 20K/function call (and yes, we do care about code size - embedded system). One thing that I have found with boost is that by providing powerful concepts in its libraries it can replace a lot of bloatware libraries/frameworks in a way that reduces overall code size, even though toy benchmarks might indicate otherwise.

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.

Absolutely agreed. Some of the stl tradeoffs don't fit some systems - hence boost:array for example...

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.

Yes - maybe something like that disclaimer would be a good start in an introductory overview. It is ultimately up to the library user to eveluate these issues - nothing special about boost in that regard.

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.

A user would have to determine that from an understanding of what a boost::function really is/does and an understanding of their application of it. In my opinion a statement similar to the above isn't a reasonable way to present usage guidelines for boost::function. If you need a generalised function interface in an inner-loop (hopefully rare) I can't see that boost::function is going to be out-performed significantly by anything else. If you are using a generalised function object interface for invoking functions where the cost of an indirection in the call is a significant part of the cost of the function (and the performance actually matters) you have a design problem. As to code size - there will always be places where code size matters, but I haven't seen a problem - maybe a system where there are a huge number of different boost::function specializations?

That doesn't make the library worthless, in fact, adding advice about the best situations to use the library enhances its value.

I agree - I really was asking you/your colleague to provide some information to turn the FUD into something valuable. I don't think boost::function needs any more guidelines, it is pretty well documented. The only one I'd suggest emphasising in an introductory coverage is: Carefully consider whether using boost::ref to avoid copying the target function object is necessary/desirable for performance and/or semantic reasons using boost::function. I just checked, and this is covered in Douglas Gregor's tutorial anyway. Maybe the guideline should just be RTFM..... Regards Darryl Green ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################