Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-08 13:02:39

on Wed Aug 08 2007, "Robert Ramey" <> wrote:

> David Abrahams wrote:
>> on Wed Aug 08 2007, "Robert Ramey" <> wrote:
>> Then, as with the Python library, we have the opposite problem: most
>> other libraries are dependent upon Serialization.
> Hmm "we"?

Umm, yes. Like it or not, we're all in this together. Dependencies
can cause problems for the maintainers at both ends of the relation.

> I would say that if that is a problem, it would be the problem of
> the library maintainer and he can/will decide how much he wants to
> depend on another library. I don't see the serialization library
> any different than any other library in this regard.

It's very different, because it's not an implementation detail. If I
write a library of containers, nobody will come to me complaining that
"your library doesn't support type_traits." They are likely to
complain that I don't support Boost.Serialization (or Boost.Python).

> Of course if the library maintainer wants to make serialization of
> his types an optional part or of his library he's free to do so
> using a command line arguement to bjam or whatever. But still - its
> up to him -

Of course it's up to him. Who implied otherwise?

> its not a boost problem.

When it becomes an issue that many library authors have to deal with,
it becomes a Boost problem. If everybody deals with it in a unique
way, we will have more problems than if we have a coherent pattern to
follow that minimizes release and testing problems.

>> In reality, python bindings and serialization code are separable
>> and optional parts, and we ought to have some way to treat them as
>> such from the point of view of the testing and release processes.
> Most of the other libraries which contain serialization code
> have a separate (and optional) header for it (similar to
> the headers in the serialization library for stl collections) so
> I don't think there is a lot to be concerned about here.

If serialization and python become "prerequisite libraries" just
because other libraries "depend" on them, that's a big problem. These
problems are not insurmountable, but they deserves attention.

Dave Abrahams
Boost Consulting
The Astoria Seminar ==>

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