Boost logo

Boost :

From: Julio M. Merino Vidal (jmmv84_at_[hidden])
Date: 2007-04-03 17:57:21

On 03/04/2007, at 22:54, Jeff Garland wrote:

> Right, and best case, you're into an hour or two of fiddling around
> that had
> nothing to do with what you were trying to accomplish -- which is
> simply to
> read the docs and use the library. And while I understand the
> sentiment the
> C++ programmers have been dealing with this for years, etc, etc..
> it's still
> really nice when getting started with a new lib that the barrier to
> entry is
> more like a scripting language than traditional C/C++ libs.

Exactly. I have recently been experimenting with other languages,
and their ability to painlessly install and use external modules is
great. In C/C++, it's certainly more difficult, and in the case of
Boost, it is painful for binary libraries. And I know what I'm
talking about fairly well: I'm the maintainer of the Boost packages
in pkgsrc (a package system that runs under e.g. NetBSD and OS X) and
I had a very hard time to get the packages to work and to get those
programs that need the binary libs to compile fine. The "suffixes"
and versioning of Boost make things more complex when compared to
those libraries built by the typical automake/autoconf/libtool
system. (I have almost no experience with Win32, so I don't know
what problems arise there though.)

When I was suggested to code Boost.Process as headers-only, I was
reluctant at first but came to like it in the end. The easiness in
using the resulting library is very convenient, and you avoid all the
problems of binary libraries.

I wish I could avoid having to convert the library to binary just
because Boost.System... but I've been told recently that Boost.Asio
has the same problem...

Julio M. Merino Vidal <jmmv84_at_[hidden]>

Boost list run by bdawes at, gregod at, cpdaniel at, john at