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.
|