Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-02-02 14:48:41
Peter Dimov-2 wrote
> These headers (along with their dependencies), or some subset of them, can
> be separated into a "serialization core" module.
OK then the "serialization core" needs tests - right? then wouldn't the
serialization core module depend upon the archive part of the serialization
library? Wouldn't that suck in the everything else as it does now.
if one uses date-time but doesn't include date-time/serialization and
everything works - how can one say that date-time is dependent upon the
> Doing this right might still be a significant undertaking, of course. A
> cursory look shows that map.hpp includes
> boost/archive/detail/basic_iarchive.hpp, for instance.
If one just included the header things might work - until someone needs to
actually invoke the serialization of the type - at which case - either
you've got a missing function when you try to link or you've had to make the
serialization library dependent in any case.
> On the other hand, it's possible to start with only the part that's
> straightforward and advance incrementally towards the goal.
For what it's worth, the serialization library namespace is already divided
into "archive" and "serialization" since the very beginning with the exact
idea of separating the serialization from the concept of archive. I caught
a huge amount of strident criticism for doing this (much more than the
current incident). But It looks to me that things are already structure
more or less as you are recommending - but that this doesn't show on the
dependency graph because the graph tries to implement a concept of module
dependency rather than header dependency.
-- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-Rewrite-and-dependency-free-version-tp4671061p4671936.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk