Re: [boost] 5 Observations - My experience with the boost libraries

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2010-03-26 06:52:35

Markus Werle wrote:
> Could you please give an example where using a boost library
> did not pay off and where the effort invested was in vain?

Did any of you ever realized that this question is not fair? (Even rhetorical questions should try to stay fair.) Do you really think that any of us wants to openly blame a boost library like you propose, especially knowing that the author has put a lot of effort into it, and is in principle still around?

Yes, there was such a boost library. Instead of naming it directly, I will describe the issues it had. If you recognice the library, good for you, but please don't tell the name.

1) "operator=" shouldn't have unexpected behavior. What is unexpected behavior with respect to "operator="?

One possible implementation of "operator=" can be found at <http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/>:

T& operator=(T x)    // x is a copy of the source; hard work already done
{
    swap(*this, x);  // trade our resources for x's
    return *this;    // our (old) resources get destroyed with x
}

An implementation of "operator=" that has a significant different semantics from this is unexpected. I think the above "operator=" would even be correct for "auto_ptr", so I really believe that this statement contains some truth.

2) Don't inherit from concrete classes. This is something much more subtle and actually quite an iteresting lesson I learned from this practical example. One of my collegues tried to educate me about this before, but I couldn't understand why he thought this would be important. It's a bit tricky to explain without showing actual code and its concrete issues. The mentioned boost library provided a sort of container, but there was no "swap" functionality. I tried to add one (among others to enable me to write "operator=" in the canonical way), but soon found out that this won't work out well, because of the inheritance hierarchy using concrete classes.

3) A significant runtime overhead for some common tasks and a TODO item in the documentation to investigate this and find out whether it can be fixed.

I guess I already said much too much, but I wanted to really make it clear and concrete that this question is not fair, so here we are now.

Regards,
Thomas