monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] 3rd party libraries


From: Zack Weinberg
Subject: Re: [Monotone-devel] 3rd party libraries
Date: Thu, 23 Oct 2008 18:01:40 -0700

On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <address@hidden> wrote:
> On IRC we recently had a discussion about using boost::date_time instead
> of rolling our own in dates.{cc,hh} - as I've been doing in nvm.dates.
> I've been under the impression, that we do not want to rely on boost
> libraries. But in nvm.stripped I'm working on linking monotone against
> other libraries as well, so it seems we need to revisit the question of
> how to work with 3rd party modules in general.

In this message I just want to address the boost situation.  I feel
very strongly that we shouldn't use any boost module that isn't
"header-only" ever again, and that we should maybe even stop using the
header-only modules as well.  This is an extreme position but I think
it's justified:

The boost modules with link libraries do not present a stable ABI.
The number one cause of segmentation faults in monotone used to be
that the binary was being dynamically linked with boost libraries that
weren't an *exact match* for the headers it was compiled with.  Since
we stopped using those, I can't remember the last time we had a
segfault reported.  By me that's sufficient reason not to use them,
all by itself.  We could bundle them, I suppose, but we never did that
in the first place because - as you mentioned yourself - the boost
build system is nonstandard and difficult to work with.  It becomes
significantly less troublesome if you only want header-only libraries,
but it's still fiddly enough that it's not worth it IMO.

It's true that boost::regex was bloated (or rather, in many distro
builds it dragged in the bloated ICU libraries, whose functionality we
weren't even using) but that was secondary to the ABI problems in my
estimation.

Also, all of the boost modules (header-only or not) are code we do not
control that is written right at the bleeding edge of the C++
standard, and therefore has caused trouble with new-and-pickier or
old-and-buggy compilers in the past, on several occasions.

Finally, it has been my experience that many of the boost modules
present abstractions that are a poor fit for what we need in this
project.  boost::fs was a good example -- it wasn't just slow, it was
causing impedance mismatches *everywhere* we had to convert from
boost::fs objects to internal path objects or vice versa, and there is
still a lot of code in the current tree that's slower than it should
be because I never finished cleaning it up after we got rid of
boost::fs.  And you know how we've never done non-ASCII file names
correctly?  That's because boost::fs made it impossible.  We could do
it now, it would just involve a lot of code auditing.
boost::date_time was inflexible and not portable enough (it got time
zones wrong on Windows, if I remember correctly).  I wasn't paying
close attention to the brief use of boost::program_options, but I am
not surprised it was trouble, either.

Of the boost modules we still use, though, I really only have a
problem with boost::format.  It's big, slow, and its authors refuse to
implement the numeric format specifiers correctly, which means ugly
casts are required in a few places.  The smart pointers, the random
number generator, the tokenizer, lexical_cast, etc. those I'm fine
with, API-wise.  I mainly think we might want to consider not using
them because of the compiler trouble they have caused in the past, and
I'm not sure it would be worth the programmer trouble of coming up
with replacements.

Also, I've read the boost::asio docs and I actually think that would
be a good thing to be using.  The abstractions look sane, the author
appears to understand what you need to do to get a stable C++ ABI, and
it would certainly be an improvement over the unmaintained 'netxx'
thing we have now.  But I'd much rather we used it in its standalone
"libasio" incarnation, that doesn't pull in any other boost modules.

I'm going to send another message that responds to the rest of your
points, including the dates stuff.

zw




reply via email to

[Prev in Thread] Current Thread [Next in Thread]