The bug in shared_ptr<T> w.r.t. C++ 11 was
patched after boost 1.47.0:
https://svn.boost.org/trac/boost/changeset/73202
Does the boost development team ever patch earlier releases?
As far as I can tell, you either end up with staying at an earlier
version with bugs or going to a newer version that breaks backwards
compatibility.
I wonder if it would be feasible to fork off boost python as
a project that does not depend on boost in its exposed
interface.
On 08/22/12 04:37, Christopher Horvath wrote:
I would love it if we could somehow help the
boost project fix this problem, which does seem fixable, rather than
abandon boost - I do think it's a great project, if it could just be
more robust in this way.
On Tue, Aug 21, 2012 at 9:29 AM, Piotr
Stanczyk <address@hidden> wrote:
Interesting
... what's the bug you mention?
I suspect that boost python is the rationale for many a projects
dependency on it.
Piotr
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.
--
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.
|