Boost logo

Boost :

Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-06-15 12:52:10

Appologies if you've seen this before. I've had problems with Google groups
so I don't know if anyone saw this. I'm trying Nabble now.

I remember that you originally brought up the question of "bridging" headers
and I thought about that.

Take for example the serialization library. The multi precision library
implements the code required by the serialization library in order to
save and restore multi precision data types to an archive. So it includes
some headers from the serialization library.

But is the multiprecision anyway dependent upon the serialization library?
Well, most people will using multi precision without needing or wanting
the serialization library. So should the current dependency scheme is
going to be found wanting for those people.

Before someone comes ups with the great idea - "just move all the multi
serialization code in to the serialization library itself consider the
from the serialization library point of view. Now he is "dependent" on
multi-precision library even though he doesn't use it. We've just shifted
the problem from one place to another.

So consider saying that multi precision serialization is a separate module.
Aside from the proliferation of modules and confusion that this would
entail there's still a problem. Running the tests for a library depends
on still more modules. Since I would like to see more users run the
test suite for the modules they use on their own environment then
we've got some other dependencies.

Basically - we just have to recognize that our "dependency minimization"
efforts will never be definitive. But I think the exercise is useful,
especially the breaking of cycles and eliminating gratuitous dependencies,
as long as it doesn't become an end in itself.

Robert Ramey

View this message in context:
Sent from the Boost - Dev mailing list archive at

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