I'll chime in here and say that Christopher has done a good job of describing the fundamental problems with
boost.
For something that is supposed to be the an example of best practices for
C++,
boost sure gets in wrong with regards to maintaining backwards compatibility.
Even if you are only using boost headers, you can introduce boost version dependencies referencing the types in your interface.
When an application uses a version of
boost in its SDK, it becomes very annoying.
The
boost website itself recommends choosing one version of
boost and using it across your whole project. It is like they've never come across the concept of dynamically linked plugins that are developed independently.
For what it is worth, the
boost implementation of
shared_ptr<T> up through
boost 1.47 has a bug with respect to
C++ 11. I suspect this bug could be in some other
boost types as well.
On 08/21/12 04:14, Christopher Horvath wrote:
The problem has to do with versioning and namespacing. Because there's no hard & concrete rule for how boost is compiled, linked, versioned, and installed - it becomes extremely difficult to prevent a compilation that depends on boost
from finding one version of the headers in one location, but linking against libraries in another location, or something similar.
This problem keeps rearing its head, and I keep thinking we must have some sort of consensus solution to it, since it's seemingly solvable. Yet, here at work, our default distribution of linux puts an unversioned boost directory in /usr/include and /lib
- so I have to carefully check all of my makefiles to make sure they're looking in my versioned boost installation, say, "-I/depot/bundles/july2012/boost/boost-1.49.0/include" or "-L/depot/bundles/july2012/boost/boost-1.49.0/lib", and try to prevent them from
looking in /usr/include or /lib first.
Furthermore, boost doesn't put versioned namespaces in its own code, and due to its popularity, this is a very big concern - if two software components are trying to interact, one of which was built with boost 1.39 and one which was built with boost 1.49,
all sorts of problems will ensue. I can get around most of this by only using statically linked libraries, and avoiding making boost objects (other than smart_ptrs) publicly visible outside the libraries, but still, it's a huge pain.
I've been in multiple discussions where people have entirely dismissed using Alembic to solve a problem that it would be perfect for, just because of the boost dependency.
On Mon, Aug 20, 2012 at 9:03 AM, Larry Gritz
<address@hidden> wrote:
I'm not sure I understand people's objection to Boost, especially for the portions that are header-only. It's solid, very well-vetted, nicely cross-platform (HW, OS, compiler), and you can be confident that it will continue being maintained for
a long long time. With high frequency, its solutions to problems are sufficiently best-of-class that they become part of the C++ standard itself, with few changes.
Now then, when I write software, I am careful to only use Boost *internally*, I never ever allow one of their types to become part of my public APIs. The design of its packages do vary in their elegance, and I only use a subset. I second the notion that
there isn't an especially good substitute for boost::python (though I would be happier if it had been part of the Python distro itself).
On Aug 20, 2012, at 8:38 AM, Christopher Horvath wrote:
Assuming C++11 is being used for the "tr1" stuff that boost provides, the big dependency that's difficult to shake is boost::python. It's absolutely wonderful for what it does, elegant and lightweight. I've tried swig as an alternative, and it's okay,
but boost::python is definitely nicer.
On Fri, Aug 17, 2012 at 9:32 PM, Richard Addison-Wood
<address@hidden> wrote:
Personally, I would recommend avoiding any dependencies on boost.
--
I think this situation absolutely requires that a really futile and stupid gesture be done on somebody's part. And we're just the guys to do it.